OpenTweet - distributed twitter-like service?
Scott Hanselman in this tweet (and on his blog) proposed a sort of a distributed tweet server to serve as an alternative to Twitter. He points out that this has been proposed before, and even implemented to some degree.
On the surface, Twitter is a feed of messages — combined with many ways of getting messages to the service, as well as many ways of getting messages from the service, plus a framework for subscribing to others’ feed and seeing others’ friends’ feeds.
A single user can certainly host their own feed, and (via some soon-to-be-established) microformat link to this feed. Assuming that we discount the issue of maintaining your own feed, how will people find your feed? How will they subscribe to it in a way that incorporates the rest of their friends’ feeds? How will replies and direct messages (both excellent features of twitter) be implemented in such a model? Let’s dissect these in more detail.
Finding a feed
The low-tech, least-usable way of doing this is, of course, to just tell the reader to find the publisher’s site, find the tweetfeed link, and add it to their reading software. In practice, this won’t really work: nobody wants to search the net to find your tweets. My suggested solution: a set of web sites where users can register; a federation of registration servers, of sorts. So firstname.lastname@example.org may be my default indexing location; yours may be email@example.com. If each server publishes a list/directory of nicknames (usernames) in a standard format, we can build search engines to search these registries. In theory this will mean some networks will be effectively private until a search engine finds them, but such is the normal mode of Internet operation anyways.
Subscribing and reading
Feed consumption need not be anything fancy. Something akin to online or offline RSS readers will be enough, albeit probably optimized for very short messages without bodies. When you subscribe, you subscribe to the tweetfeed of the publisher; your reading software will integrate all the tweets into a single, coherent timeline.
Replies / direct messaging
In order to support replies, we need to determine how we will address users, and how we will deliver the messages. I’m commingling replies and direct messages here as follows: to me, replies are public messages plus notifications to the target user that a new reply has been created, while direct messages are notifications to the target user that contain the reply, and the reply is not posted to the feed.
So how do we address users? The @user syntax is a very convenient one, so we can try to piggy-back on that by having @user mean user@SERVER — and the SERVER is my default registration server. If I want to address a user on another server, I can always use the fully-qualified @firstname.lastname@example.org. So for example, let’s imagine that there are three users in the world: john@serverA, jane@serverB, and jeremy@serverA as well. When john wants to reply to jeremy, he simply needs to start the reply with @jeremy, since jeremy is a user on the same server. When replying to jane, however, john would need to start the reply with @jane@serverB. Perhaps client software can make this easier via address book lookups. When john’s tweetfeed is published, the feed contains john’s default server name, serverA. A client consuming the feed would know how to resolve the usernames, and thus where to look up these other users’ feeds.
So that’s addressing, now what about delivery? This may be approached much like trackbacks: a standardized way of submitting a short snippet of data to your registration server. In a way, your registration server is your notification server. Some servers may be configured to forward the message on to your own tweet feed engine as an actual comment-like post; others may email you; others may publish a reply-feed that you may then consume with your own reader. This will then solve the problem of the privacy of direct messages as well — your private reply-notification and direct message feed will only be known to you.
Finally, we need to address spam. In a distributed system, combating fake-reply or direct message spam may not be trivial at all. My initial thoughts are to a) force reply messages to include a computed hash of some value from your feed, or b) have the reading software filter out any messages from people that it knows aren’t your friends, and requiring your friends to include a public key in their feed and to sign their messages with their private key.
This may all be a bit overkill, but on the other hand may result in a nice, friendly Twitter-like service that doesn’t really lose any of the functionality that makes Twitter so attractive and even gains some capabilities to create private networks.
Oh yeah, and follow me at http://twitter.com/haykinson