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.
"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
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
or
"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
or
"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
. 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?
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. 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.
I suggest each personal domain's _microblogging.example.com has a TXT to show the current status.