Payloads for Twitter
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.
Context & Ripple Effects
The argument runs back through Winer's own year of Twitter writing: in March he was asking how basic Twitter really is and probing where its future lay, and by July he had answered practically with TwitterGram, an audio-tweet tool that both Webware and TechCrunch picked up.
What this post changes is the form of the argument. Rather than shipping one more hacked-together app, Winer reaches back to his own 2001 document, Payloads for RSS — which laid out how to attach content to an item without dictating how apps would show or play it — and suggests, though he frames it as a possibility rather than a settled case, that Twitter has reached the equivalent stage.
First-order effects
- Developers building on Twitter get a concrete template for attaching enclosures to tweets, one that TwitterGram's working audio posts have already exercised end to end.
Second-order effects
- Twitter faces the fork RSS faced after the 2001 payloads proposal: bless a shared attachment convention in its own API, or leave third-party clients improvising incompatible formats for displaying and playing attached media.
Third-order effects
- If the RSS precedent holds, a user-drafted payload spec arriving ahead of official support would let independent clients — not the platform — define how media-bearing short messages look and play, setting the de facto standard first.
The trend: Microblogging is tracing RSS's arc from plain-text items toward structured attachments, with user-drafted specs landing ahead of platform-native support.