Payloads for Twitter posts
Friday, September 28, 2007 by Dave Winer.
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're at a similar place with Twitter. Sometimes I want to answer the question Twitter asks, "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.
Today the Twitter pipe is narrow, and some people, for good reasons, want to keep it narrow. I think we can have our cake and eat it too. But first let's take stock of where we are now. What metadata is stored with a post today? It seems only four bits are there: 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 itself.
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.
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 whole 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.
