Open Source microblogging | Hacker News Reader

Open Source microblogging

status.net

33 pointsyannis19 comments

What we need is not only open source microblogging, but also distributed, decentralized microblogging network.

I suggest each personal domain's _microblogging.example.com has a TXT to show the current status.

That's what StatusNet is; it supports the OStatus protocol: http://ostatus.org/

Google is also creating a (incompatible) federated microblogging system using Atom+WebFinger+Salmon. http://www.google.com/buzz/dclinton/HeMv1AQTXS8/Envisioning-...

The protocol spec links on the OStatus site seem to be dead.

The spec has now been posted: http://ostatus.org/sites/default/files/ostatus-1.0-draft-1-s...

I find this new Web 2.0 flavor of spec mashup as hard to follow as a Twitter conversation. I wish people would provide a complete spec (if only as an "informative" adjunct to the real spec) rather than including-by-reference ten different sub-specs, none of which make sense in isolation.

What's the difference/relationship between OStatus and OpenMicroBlogging? Are they the same thing or something?

I tried looking into OMB for a side project about a year ago and had a very hard time finding any clear documentation, and just looking again now it doesn't seem any easier.

There seems to have been a mass renaming; Laconica/Identica became StatusNet and OMB became OStatus.

Laconica -> StatusNet

OMB -> OStatus

Identica -> Identica

Would something like this maybe work?

Decentralized microblogging protocol

------------------------------------

"Microblogging" is the generation and recipient-directed distribution of short (typically less than 140 characters) posts. There are four fundamental actions: making a post, requesting past posts, and subscribing and unsubscribing from future posts. A "post" is a piece of text produced by a user at a particular time.

Given an open connection to a microblog server, here is how each of the four actions works:

1. making a post

The user sends one line:

"post " <username> " " <secret> " " <text> CR LF

If the username or secret contains spaces, double-quotes, or backslashes, or is empty (for example, if the user connected over SSL with a client cert, there is no need for a secret), it must be enclosed in double-quotes and any double-quotes or backslashes preceeded with a backslash. The server responds with either

"ok" CR LF

"error " <message> CR LF

2. requesting past posts

The user sends one line:

"request " <requestee> " " <n> ["posts"|"seconds"] CR LF

The server responds with any number of lines of the form

"post " <timestamp> " " <text> CR LF

where <timestamp> is the time that particular post was made, as seconds since 1970-01-01 UTC, and <text> is the text of the post. There should be one line for each post made by the user <requestee> not more than <n> seconds old, or one line for each of the last <n> posts made by <requestee>. After sending all the posts it will send, the server should end with a line

"done" CR LF

3. subscribing to new posts

The user sends one line

"subscribe " <requester> " " <requestee> CR LF

to request that the server forward any posts made by <requestee> to the requester by connection to the microblog daemon on the host the connection was made from. The server responds with

"ok" CR LF

"error " <message> CR LF

4. unsubscribing from new posts

The user sends one line

"unsubscribe " <requester> " " <requestee> CR LF

to request that the server cease forwarding posts by <requestee> to <requester> at the connecting host. The server responds with

"ok" CR LF

"error " <message> CR LF

Subscribing (and unsubscribing) require a way for a microblog server to forward posts to another server. So we have a fifth action:

5. forwarding posts (server-to-server)

The origin server connects to the target server and sends one line

"forward " <requester> " " <poster> " " <timestamp> " " <text> CR LF

. The target server responds with

"ok" CR LF

"error " <message> CR LF

. In the case of an error response, the origin server may wish to pretend that the target user has unsubscribed. A server may try to forward posts to non-subscribed users, but shouldn't be surprised if it gets an error response.

...what would be good ports for this, 5544 for plain and 5545 for SSL?

Why invent a new protocol for this, rather than just using HTTP?

How would that help? You'd still need to put just as much work into defining request and response formats, so it would just be a useless layer of bloat.

1. Every language under the sun would already have a client library for talking to it

2. Existing mechanisms for scaling HTTP (caching proxies, HTTP-aware load balancers) would work out of the box

3. HTTPS would be available if you needed it

4. You wouldn't need a new port assigned, and existing firewalls wouldn't need to reconfigured.

5. You wouldn't get people like me asking "why not just use HTTP?"

XMPP might be suitable

1. Using HTTP does not save having to properly format requests or parse answers. What makes exchanging messages by means of an HTTP library easier than exchanging messages by means of the socket library that that HTTP library is built on?

2. Hm, maybe. Or maybe using HTTP would increase the need for such mechanisms. ...How much would be cacheable, anyway? About the only thing would be fetching past posts, and I'd expect most of that to come from web frontends anyway (which would have their own caching).

3. HTTPS is just HTTP over SSL. SSL is available without having to use HTTP.

4. Hm. Maybe dns SRV records could be used to get around needing a port assignment, and what firewalls would actually matter? I'd think it would be like smtp/pop/imap, people just use webmail clients and their firewalls don't care.

5. :) I just don't see that requiring http for something that would in practice be almost entirely for server-to-server communication would actually provide any benefits.

...hm. I included a spec on how to make posts thinking that it could also be used by client programs, but the connect-back design for forwarding messages wouldn't work for that. :(

1. HTTP includes verbs to handle everything you mentioned. Posting is a POST, listing is a GET, getting a single message is a GET, subscribing is a POST, deleting is a DELETE, etc.

2. Many networks use proxies and caches such as squid, varnish, etc. My servers are locked down with iptables, and I would have to open up ports in order for them to speak a new protocol

3. What's your point? Your protocol is just a layer over TCP. Why not just use TCP? And TCP is just a layer over IP. Why not just use IP? Following your logic takes us back to early DOS days where each program drives each piece of hardware directly.

4. Your argument against using HTTP is that ... people are just going to use HTTP anyway?

5. With libraries such as Rack and WSGI setting things up to speak HTTP is too easy. Not to mention node.js, mochiweb, etc.

TCP provides reliable streams, which IP doesn't. HTTP takes those reliable streams and provides... what, exactly? I guess it turns the streams into request/response message pairs (with lots of extra headers), but that's not nearly as useful - especially since parsing messages out of a stream really isn't harder than understanding the contents of the messages themselves.

Why is this better than OpenMicroBlogging, pubsubhubub, or whatever it is StatusNet uses? And why are you not using HTTP? And if you're making a new protocol, why have an unencrypted connection?

an example would be great; i'm confused about what this is. the open source part indicates technology, but the site looks like some guy offering consulting to businesses.

http://identi.ca/ is a public microblogging site running the laconica/status.net software.

Is status.net a rebranding of laconica, or a fork of some sort?

edit: looks like a rebranding http://status.net/2009/08/28/laconica-is-now-statusnet/

Reply on news.ycombinator.com