Archive for July, 2009

Would I-Names make good Twitter username replacements?

July 13, 2009

Yesterday I wrote to Twitter:

Can't have a new decentralized Twitter without short usernames! XRI I-Name evangelists should be all over this! #openmicroblogging #xri

Nik Putnam replied through Facebook:

why not? your reader could translate between URIs for contacts and your own nicknames for them, like your mail client does. no?

To which I added:

That's the model we have for Borange, and I think it's ultimately the right one.

I've just been thinking about what makes Twitter Twitter, though, and I think one has to consider how the simple username namespace contributes to the usability of the system.

Basing "world-wide conversation" on personal Address Books, as you suggest, means there's no "objective" unique naming that's short. URLs especially can be confusing. Is some new "http://id.me/masonlee" going to be me?

Getting URIs out of your Address Book based on the person's common name requires some fancy UI-- more than simply typing =masonlee. Twitter success has been due to ease of use and ease of client development.

...

I-Names certainly aren't "decentralized", though, so they won't make for a decentralized Twitter-- just a more distributed one. They do have the benefit of being controlled by a foundation, aren't based on DNS, and have an interesting layer of indirection that allows the namespace to evolve.

So what’s up with I-Names these days, anyways? Last news I heard was support for them in OpenID 2.0.

=masonlee

RSS and Atom feeds are not appropriate schemas for a new distributed Twitter.

July 11, 2009

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.
  • Datestamp.
  • 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?