Developers: how will we all get along with Twitter’s annotation feature?

Today at the Twitter Chirp Hack Day I talked with a ton of developers and the new feature they were most interested in. Adam Jackson echoed everyone I’ve heard today when he tweeted “Twitter Annotations is what I’ve been wanting FOREVER.”

We’ll be posting those interviews next week on building43 but there’s a lot of questions and not a whole lot of answers as to what Annotations are, so I figured I’d post what I learned today.

First, Annotations let Twitter clients attach metadata onto a Tweet.

Some things I’ve learned:

1. Annotations can be up to 512 bytes in length (although that limit hasn’t been decided for certain yet). That would let you put slightly more characters into the metadata payload than would be allowed in a tweet.
2. The metadata can ONLY be written at the time the Tweet is published and can NOT be changed or written later.
3. To get around limitations of non-updateability developers are already working on systems to point out from the metadata to other systems that CAN be updated.
4. Twitter has not disclosed how this metadata will be displayed yet (this feature will only be available to developers at first, later will be turned on first on and maybe not used at first on Twitter’s other clients).
5. There aren’t many rules as to what can be in this metadata. YET. All the devs I’ve talked to say they expect Twitter to “bless” namespaces so the industry will have one common way to describe common things. More on that in a second, but Steven Hodson already explained well why this new metadata payload could turn into a nightmare for Twitter. Twitter has already started communicating about some of the rules that will be coming.
6. Annotations won’t be available until next quarter, in other words, at least not until July.
7. Not sure what the experience would be like on all Twitter clients (obviously they won’t be able to be delivered to SMS clients, for instance).
8. There are a few more details already on the Twitter Development Talk list.

So, what could this be used for?

Well, let’s just imagine a developer comes up with something new he’d like to build into his clients. For instance, today at Chirp it was sunny, so I came up with a feature for describing the weather at the location where you’re tweeting from.

The old way of describing the weather was to say “nice weather in San Francisco” in a Tweet. But that takes almost 30 characters of your 140 to do.

So, why not build a new iPhone app that lets you select the weather when you tweet? (Or, even better, automatically go out to an API at or something like that, grab the current weather for the location you’re at, and shove that into the annotations metadata payload).

Sound simple enough? It is.

Except what if my app describes sunny weather this way:


but some other developer wants to describe it this way:


And yet another developer wants to describe it this way:

weather=80 degrees fahrenheit with no clouds

And yet another developer wants to describe it this way:

weather=blue sky

Get the problem? Every client would need to figure out what the string in the metadata really was trying to say and they each might get it wrong, or might not work because some other developer used a format they weren’t expecting.

So, now, we have to have an industry conference for deciding on the right way to describe weather and we need to argue about it forever which will keep everyone from shipping a client that actually works and does something useful for users. Damn, all I wanted to do was put a nice sunny logo on my tweet in Tweetie!

Imagine this argument happening for everything.

Television show=”Lost”
Movie=”Kick Ass”
Location=”1 Market, San Francisco, CA”

I can imagine lots of ways to describe each of these things, can’t you?

Heck, to IMDB “Kick Ass” is actually “

And so on, and so forth. Mahendra gave some other examples of how Annotations could be used.

But it gets worse than that.

I might want to point my tweets at a commenting system, but Disqus will use a different code than JS-Kit will. So, now we’ll have different commenting systems that can’t be replaced later. What if Disqus goes out of business, or changes their strategy or name? Now my old Tweets won’t work?

One nice thing is Twitter’s dev team is taking an open approach with this. They want to hear from developers on their development talk page (just opened) about how you’ll want to use this new feature.

My real question is “can we all get along?”

Why is this important? Well, this lets developers build new curation, bundling, and other systems. I hope the industry can get it right.

Have you started thinking about Annotations? How will you use them?

UPDATE: I’ve been putting other posts, like this one from Liz Gannes, about the Chirp conference, onto my Twitter Favorites Feed.