It has been a long time since I got downright giddy about something developer-oriented. Lots of new APIs are coming out all the time and I usually take a once over look at them to determine if there is something cool there. A lot of time there are cool things and I promise myself to come back and explore the possibilities later. I rarely do.

However, with the announcement of GNIP today, I finally feel like my incessant mulling of API frameworks might be coming to an end.

Let me back up. A few weeks ago, I was fiddling with a bunch of APIs trying to create some mashup I was working on. I sent Keith a direct message pitching a “crazy idea”. An API for all APIs. One API to rule them all. His response, “A meta API?”

That made sense and made me laugh because I know how much he hates the word “meta”.

My idea quickly dissipated as I realized it was probably pretty futile to create an API for all these varied services that all had different data formats and types and my need for it wasn’t all that important at the time anyway.

I could have also used the concept when I was working on Mokonji, the project that now sits dead because Trackur beat me to the punch.

The idea with GNIP, bringing this story full circle, is that it is a meta-API. It sits in front of “data producers” (Digg, Flickr, Disqus) and provides a standardized API for “data consumers” (Plaxo, MyBlogLog, even Lijit!) to exchange data.

Since this is still so very early, there are bound to be other data producers and consumers. Also notable is that the only data format is XML. XMPP and JSON are missing. That will likely change over time too.

Data Producers not yet involved that should be:

• Google
• Yahoo
• Seesmic
• Viddler
• Mixx
• Twitter
• Amazon

And a few Data Consumers that are also missing:

• FriendFeed
• Facebook
• MySpace
• Clearspring

The discussion over Disqus and Intense Debate has been an interesting one. Particularly perceptive readers may have noticed me playing around with both of these services a few weeks ago in the wee hours of the morning. If you didn’t notice, never fear… it was only for a minute before switching back to my default WordPress comments.

So here’s the thing. I met Intense Debate, and perhaps Disqus, at Blog World Expo. At the same time, I met SezWho, a competitor. Each of these services offer a “social network” around commenting. But what set them apart was in who owned the data.

I use the word “own” loosely here. What I mean is, “Where is the comment data being hosted?”

There’s legitimate reasons for this. One example of why it is important for me to own the data is in the case of a legal issue or subpoena. Very relevant concern. At b5, there were several times where the Police called us asking for data about some random person on some random blog who was a person of interest in some random crime. In all cases, we could not give up data without a subpoena. When provided, we cooperated. When we were not served, we didn’t relinquish data.

This is pretty common and the bigger a property (or in b5′s case, group of properties) get, the bigger the target that is on your back.

In the case of Intense Debate and Disqus, none of this data is controlled by me. It’s controlled by them for a variety of reasons. SezWho did not host the comments which was a big selling point for them.

In the case of blogs, there are many things that can be done via mashup that doesn’t place any kind of liability on the site owner or blogger. However, in the context of comments, that is actually content.

In order for me to use Disqus or Intense Debate here – both of which I’m interested in using as it adds some nifty functionality to the blog – I need to host the content and control the styling. Without that, it’s a no-go.

El problema actual es que nuestro mapa social está prisionero en cada network social que utilizamos. Cada vez que usamos un nuevo network social, debemos recrear todo nuestro mapa social para poder aprovecharlo. El Data Portability Workgroup busca generar un estándar que nos permita compartir nuestro mapa social con los servicios que utilicemos, eliminando la redundancia actual.

Google, Plaxo y Facebook se han unido al grupo, por lo menos para estar al tanto de lo que ocurre.

El primer obstáculo a superar es que la mayoría de los networks sociales consideran que el mapa social de sus usuarios es de su propiedad y no propiedad de cada usuario en particular. El segundo obstáculo es que cada network social usa un formato de datos propio, haciendo más dificil transportar datos de un sitio a otro.

Así como las vías de tren tuvieron que ser adaptadas a un estándar para permitir la interconexión de trenes y la portabilidad de sus cargas, los networks sociales deben entender que los datos portátiles facilitarán el acceso a sus sistemas e incrementarán el tamaño del mercado. Pero para empresas establecidas como Facebook, que ya poseen un mercado y un mapa social enorme, el costo de abrirse y permitir a los demás aprovechar los mapas sociales que ellos han facilitado pudiera parecer muy alto.

De esta forma el negocio deja de ser manejar nuestro mapa social y pasa a ser darnos un servicio alrededor de nuestro mapa social. La idea es que podamos ir al mejor proveedor de un servicio en particular, en vez de depender de alguien que lo haga todo mas o menos bien. Facebook entendió esto al permitir la integración de aplicaciones independientes dentro de su ecosistema, pero manteniéndolo cerrado al mundo exterior. Google notó una debilidad en este modelo y propuso OpenSocial como una alternativa abierta. Google se beneficia de un modelo abierto, en el cual colocar sus gadgets y AdSense… pero no está claro que un sistema abierto beneficie a Facebook.

A quien si beneficia un sistema abierto es a los usuarios, ya que les permitiría escoger los mejores servicios e integrarlos a su mapa social. De este modo Flickr podría saber quienes son nuestros amigos y familiares a la hora de compartir fotos, Facebook sabría quienes son nuestros colegas a la hora de organizar un almuerzo profesional y Google sabría con quienes correspondemos más a menudo para recordarnos cuando responder a un email. Los usuarios podrán decidir cuanta información compartir y con quien.

Unete el Grupo de Trabajo sobre Portabilidad de Datos y comparte tus ideas. Quien sabe… quizás algún día sea realidad.