ilya haykinson >> blog

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 ilya@mytweetserver.com may be my default indexing location; yours may be johndoe@leettweets.net. 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 @user@someserver.com. 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.

Conclusion

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

Microsoft’s new version of IE will have RSS feed management based on the new Microsoft Feeds API. This API is also going to be used by the upcoming Office 2007, notably in Outlook.

This is actually a great development. I’ve been a big fan of using mail reader based feedreaders, and totally love the fact that now I don’t have to use third party software. What I’m not happy about is feed synchronization.

I fairly regularly use three computers: a desktop at work, a desktop at home, and a laptop that I bring back and forth. I run Outlook 2007 (beta, of course) on my laptop. However, I sometimes want access to my feeds on one of the other machines, whether because I quickly want to check one of the blogs, or because I find a site that I want to add to my Outlook reading list. But, being on another machine, I’m out of luck.

Outlook makers thought of this, somewhat. Since feeds get delivered into Exchange folders, I can actually just read the posts being retrieved by my laptop from wherever I can run Outlook. But what if I don’t want to run Outlook everywhere?

The solution has got to be feed synchronization. A simple service can receive OPML files containing your blogroll and then synchronize them across Windows devices. Run a small client software, and it keeps track of your feeds — updating any clients with changes from other clients. All your machines would of course start checking all your feeds, but that’s a small cost to pay for keeping your computing environments synchronized.

Requirements for such a service:

1. Create and manage an account
2. Support initial import of an OPML file
3. Configure itself as either a reader only, or full synchronizer
4. Regularly query the service and update the local Common Feed List with new feeds
5. Regularly query the local Common Feed List and upload any changes to the service
6. Support export of OPML file

It would really be best if a service like Bloglines just built an API for this; they already have OPML capabilities and have a feed-savvy account base.

Thoughts, anyone?