Twitter’s big announcement this week about annotated tweets and the new metadata that developers will be able to attach to tweets is a welcome one. This means that tweets about music will now be able to contain information about the artist and song name, tweets about finance will now be able to contain semantic information about the stock symbol and price, and tweets about sports will now be able to contain the teams and score, just to name a few examples.

While this will no doubt enhance the information and usefulness of any single tweet, it is also a two way street. There are no declared standards around how to use and interpret this new metadata, and therefore companies and developers can very quickly go down a confusing hole of creating protocols which conflict with those created by other companies and developers. It has been suggested that Twitter itself act as a somewhat benevolent dictator and help standardize certain popular usecases (defining the metadata format for stock based tweets for example), however Twitter has said that it will take a step back and instead look to see what emerges from the community around this role. And I think this is a good thing.

Metadata in tweets is only useful when there are two parties or more who agree to use it in one way. One party can attach this data to any tweet that their applications produce, and another party or product can consume these tweets and use the information in a meaningful way. Sticking with the stock example, someone could build a desktop stock ticker application which scrolled stock prices using current tweets about the stock within a hover effect. This only works if the company building the ticker app knows the standard metadata format that the applications producing the stock related tweets will use. Twitter won’t specify this format, so I believe there is room for the early movers in the space to create the standards themselves, and thereby create a social API in the process.

What is a social API in this context? It’s an API embedded semantically within the context of a social message. In this case, a tweet is a social entity which moves through the internet passed from friend to friend. But when its underlying data conforms to the API specification as well, it is also creating a platform upon which other services can be built. 

It is at once viral, open, and consumable.

What are the advantages to creating a social API in this manner? You are establishing a new content consumption mechanism with your service as the platform. If useful, it is already spreadable purely by existing in the twittersphere. You’ve done all of this without coding your own internal API, access points, error handling, or monitoring.

What are the disadvantages? There are a couple. First off, you’re pretty constrained by a lightweight API. I don’t believe we know the limits yet on the size or structure of the data you can include within an annotation, but it likely won’t be enormous. Second, by outsourcing your API to twitter’s universe you are making yourself replaceable. Anyone else could annotate their tweets with the same standard you defined, and they would be equally as consumable as yours. In this case, your content would have to be unique enough and important enough to remain relevant.  

Exposing a social API via annotated tweets surely won’t be for every service, but I’m interested to see those that step up early and pioneer new ways of consuming content that haven’t yet existed.

For more unnecessary insight, you should follow me on twitter.