4 ms·

Would something like this maybe work? . . . Decentralized microblogging protocol ------------------------------------ "Microblogging" is the generation an

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 or "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 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 "forward " <requester> " " <poster> " " <timestamp> " " <text> CR LF . The target server responds with "ok" CR LF or "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?

simonw 17y ago
Why invent a new protocol for this, rather than just using HTTP?
- tbrownaw 17y ago
  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.
  - simonw 17y ago
    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?"
    - aubergene 17y ago
      XMPP might be suitable
    - tbrownaw 17y ago
      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. :(

simonw 17y ago

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

tbrownaw 17y ago
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.
- simonw 17y ago
  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?"
  - aubergene 17y ago
    XMPP might be suitable
  - tbrownaw 17y ago
    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. :(