Back in 2001, I wrote a document called Payloads for RSS that explained how you could attach something to a RSS item. I didn't explain how a RSS app would display or play one of these things, that would come later.

Today, we may be at a similar place with Twitter.

Sometimes I want to answer Twitter's question, "What are you doing?" with a picture, or a bit of audio. Some people want to send videos. It's easy to imagine in the future that along with a Twit, I might also want to automatically send my location (obviously a preference), and maybe some other status information.

It seems that four bits of data are stored with each post: 1. the person who posted it, 2. the time it was posted, 3. how the post came to Twitter (web, Hahlo, Twiku, txt, twitterrific, twittergram are some examples) and 4. who it's in reply to (if it is).

Now suppose I wanted to allow for payloads, as RSS 2.0 does. The problem is a bit more complicated, because not only do we have to specify how the data is communicated, we also have to say how it's displayed.

Caveat: This is just a proposal, there are many ways to do it, this is just one way.

First, the "update" routine, as specified by the Twitter API, would add 2 optional parameters: 1. the url of a picture that's a thumb for the enclosed data and 2. the url of the data.

A couple of examples...

1. For Twittergrams, which are audible tweets, recorded on a cell phone, the image would be a small speaker, . The second paramter would point to the MP3 file.

2. For a Flickr pic, the image would be a tiny thumbnail of the picture, and the second paramter would point to the Flickr page.

Discussion...

I thought the whole thing could be shrunk down to one paramter, a pointer to a bit of text that Twitter would trustingly display, but that's the problem, you have to trust the app not to break Twitter, and we all know that wouldn't last. Even a well-intentioned delveloper can forget to close a table properly, and that would leave the Twitter display in disarray.

I also thought we might register data types with Twitter, but that's a likely black hole. Apple went down that path, so did Microsoft and the IETF. It's a lot of work to make those systems work, and it's just a matter of time before they break down in chaos.

I think that Twitter should probably handle two or three types specially because they are so common and useful. Those are pictures, audio and possibly video. But that's potentially a lot of work, and can be done later.

Some will object that this only makes sense in the web, and that Twitter is designed for SMS. To that I say two things: 1. Degrade gracefully. 2. You already have features that make sense only in the web, e.g. the pictures next to posts that show iconically who's saying what. That's a nice thing to have in the environments that can display pictures, and its presence there does nothing to diminish the experience for the environments (e.g. SMS) that can't.