RSS and Atom feeds will not a distributed Twitter make. Not because they aren’t “real-time”, but because the notion of “titles” simply isn’t conversational.
The schema of the feeds dictates to a large degree the end-user experience. Twitter’s 140 character limit has surprised, impressed, and enlightened the lot of us techies. How could such a severe limitation actually works to the end user’s benefit? Easy: it makes a tweet stream readable. If you want to publish into the conversation, you have to conform to the standards and keep it short; people are skimming this information.
Compare a Twitter.com client to an Atom feed client. Atom clients have trouble displaying information from disparate sources uniformly because not every source agrees on the semantics of “title” vs “subtitle”, nor on what to put in the “summary”, nor on whether the content embedded in the feed should be the same or different from that in the link. Re-combined Atom feed items can make for some awkward reading when you start pulling in things like photo streams, audio feeds, and Twitter statuses. Just because some information can be shoved into Atom and shown in the same feed reader as everything else doesn’t mean it should be; however, the idea that all types of Atom feeds need to be supported in a feed reader is prevalent, and has usually worked to the detriment of user experience. Even RSS’s more simple “title” and “description” are two pieces of metadata too many for today’s information glut and the new distributed world-wide conversation.
One way to get clients built for a new distributed, real-time, world-wide conversation system might be to make a new feed format that helps dictate the user experience and expectations. In doing so, we would take a lesson from Twitter: Titles are outmoded. Make your case in 140 chars and attach a link. It works.
How about a straw-man proposal then? We’ll need some some short text, the ability to attach links, and some very basic metadata to make the system work. Call these new feed items “Tweets” (and make sure they can be JSON as well as XML!).
NEW TWEET SCHEMA STRAW-MAN for distributed world-wide conversation:
- Body. 140 chars!
- Links. If you are tweeting a link or links to data (e.g. an article, photo, mp3, etc.) those links go here. The items are NOT embedded in the Tweets. (Another lesson learned from Twitter and another interesting discussion.)
- Author. A person’s internet identity. I-Names?
- Digital Signature. The whole Tweet should be signed against the author’s public key so we can verify authenticity without having to get the tweet directly from the source.
- Universally Unique ID. When you make a tweet, you generate a UUID for it (in ultimate accordance with a registry.) Tweets don’t live in any central location, and aren’t created through a central place, so it’s not a URL.
- Context. If this is in reply to another tweet, or tweets, put their unique IDs here to so clients can load conversation context.
This would be the format of the Tweet itself, independent of any message routing systems. Separate metadata in routing envelopes would help get the right tweets to the right people at the right time, but those would be routing-system specific, and a separate discussion. (“Re-tweeting”, for example, should really just be re-routing, not creating a new Tweet.)
What else would you add? What’s the best counter-argument that this should be done with Atom instead?