Home > Archive >  2007 >  September >  28

Payloads for Twitter

Friday, September 28, 2007 by Dave Winer.

A picture named keet.jpgBack 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. Permalink to this paragraph

Today, we may be at a similar place with Twitter.  Permalink to this paragraph

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.  Permalink to this paragraph

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). Permalink to this paragraph

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.  Permalink to this paragraph

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

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.  Permalink to this paragraph

A couple of examples... Permalink to this paragraph

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

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. Permalink to this paragraph

A picture named hebrewHunk.jpgDiscussion... Permalink to this paragraph

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. Permalink to this paragraph

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.  Permalink to this paragraph

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. Permalink to this paragraph

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. Permalink to this paragraph

© Copyright 1994-2007 Dave Winer Mailto icon.

Last update: 9/28/07; 7:49:27 PM Pacific. "It's even worse than it appears."

Click here to view blogs commenting on  RSS 2.0 feed.