error 500 Tecnología + Internet + Conocimiento

Mucho se está hablando del anuncio por parte de MySpace de unirse a dataportability y su acuerdo con Yahoo, eBay y Twitter en la primera acción concreta en ese sentido, que han llamado "Data Availability". Esta "Data Availability" no significa realmente que el usuario pueda coger sus datos y el contenido generado y llevárselo a otro servicio de forma sencilla, sino que los perfiles públicos, fotos, vídeos y redes de contactos en MySpace estarán disponibles en el resto de servicios que han firmado el acuerdo. Así, como se muestra en la imagen, desde Twitter se podría acceder a la cuenta MySpace y automáticamente incoporporar blogs y demás información que allí tengamos. La primicia la dieron en TechCrunch.

El protocolo por el que desde Twitter, Yahoo y eBay podremos acceder a los datos de nuestro usuario en MySpace es Oauth, del que hemos hablado mucho por aquí y que permite hacerlo sin dar nunca nuestra contraseña en MySpace al sitio desde donde queramos acceder a los datos. Esto, aseguran desde MySpace (Ben Metcalfe) es sólo el comienzo y no se plantea como algo sólo para Twitter, Yahoo y eBay, sino abierto a cualquiera en el futuro.

¿De que va esto realmente?

Pues de momento no va realmente de "portabilidad de datos" , de hecho desde la organización de dataportability se responde indicando que "la iniciativa de MySpace evolucione hacia una implementación más acorde con las mejores prácticas de DataPortability". Lo que se está planteando sobre la mesa es que MySpace sea el sitio que almacene los datos del usuario para toda la web. No se trata - al menos como está planteado ahora - de que poder llevárselos a otro sitio a modo de exportación, sino de que MySpace juegue el rol de identificador del usuario en la web y de contenedor de su red de contactos para cualquier otro servicio. Su propuesta es que, si almacenamos nuestros datos con MySpace, estarán disponibles en un montón de sitios más que se van a integrar con ellos.

Algunos análisis de la "jugada" en ZdNet, universos paralelos. Nota de prensa en alleyinsider.

Aunque sigo esperando la invitación, no quería dejar de comentar Yahoo Fire Eagle, propuesta de plataforma para la geolocalización del usuario, de momento en beta cerrada. La idea de Yahoo Fire Eagle no es la de un producto para el usuario final, sino la de un sistema que permite a otros servicios externalizar la tarea de geoposicionar al usuario y acceder a esos datos a través de un API. Se trata de un nuevo paso hacia el siempre localizados con un enfoque interesante, el de permitir centrarse en las funcionalidades extras, dejando la tarea de la localización a Yahoo.

¿Cómo funcionaría entonces esto? En principio Yahoo Fire Eagle permitiría localización activa (envío un SMS con donde estoy, relleno un formulario en una aplicación cliente) y localización pasiva (instalo una aplicación que toma datos del GPS del móvil y le permito enviar datos, también sería posible utilizar triangulación GSM como hace la nueva versión de Google Maps). En ese segundo caso, se envía un correo al usuario periódicamente para indicarle que está siendo localizado y en todo momento tiene la opción de borrar toda la información de Yahoo Fire Eagle. Cómo abordar la localización pasiva y hacerla compatible con el derecho (y la sensación) de privacidad va a ser una de las asignaturas más importantes para los servicios basados en la posición del usuario.

El siguiente paso sería autorizar a otras aplicaciones y servicios para acceder a estos datos. Por ejemplo, el usuario podría permitir a Flickr tenerlos para añadir la posición geográfica en la que fue tomada una foto. Para ello se utilizará Oauth, el estándar para comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario.

El potencial de servicios basados en localización es muy amplio. Desde actualización automática en servicios tipo Facebook o Twitter, hasta integración en redes sociales para localizar a amigos, pasando por su uso en búsquedas desde el móvil. Lo que puede aportar Yahoo Fire Eagle es el facilitar una plataforma en la que delegar la captura, almacenamiento y gestión de este tipo de información. Para explicarlo mejor, un esquema de como funcionaría:

Sitio oficial: Fire Eagle. Un análisis interesante en Venture Beat

Tenemos nueva API de contactos de Google, la anuncian en blog oficial y básicamente permite a aplicaciones de terceros acceder a la lista de contactos de un usuario del universo Google (GMail, Reader, Talk). No se trata de la anunciada API social de Google basada en XFN y FOAF, sino de extraer información de la red social generada intrínsecamente a través del correo, Talk y Calendar.

¿Qué permite hacer esta nueva API? Pues para el usuario final significa poder importar sus contactos en el universo Google a otros servicios (los que implementen la API, claro) sin necesidad de darle su usuario y contraseña de GMail, lo cual no dejaba de ser una locura si lo pensamos bien: en esos casos se está dando acceso al correo, a documentos, a lecturas, a servicio de estadísticas, a Checkout... como se pide en sitios como Facebook. También hay opciones para la administración de contactos desde esos otros servicios, añadir, actualizar datos, borrar un contacto...

Aclaración: si se te pedirá el user/pass, pero la aplicación cliente no tendrá acceso a los mismos. Funciona con Authsub, que es muy similar al concepto de Oauth que hemos comentado por aquí.

En principio un movimiento interesante en torno al movimiento dataportability, aunque a bote pronto a uno le surgen un par de dudas. Sigo pensando la lista de contactos generados en un contexto y sus datos personales no son precisamente los datos que se deberían poder llevar de un sitio a otro sin el permiso de los mismos y que la red social basada en GMail no sirve, que nos hayamos intercambiado un correo no significa que seamos "contactos". En todo caso, creo que es una API que puede dar mucho juego y que sería interesante analizar junto a la de Windows Live Contacts API (sitio oficial.

Para valorar en su justa medida OpenSocial, creo que hace falta echar un vistazo a Oauth, un estándar abierto cuyo último borrador fue lanzada hace apenas un mes. Oauth define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña.

Imaginemos que queremos programar una aplicación tipo "página de inicio para el usuario", en la que este pueda añadir sus fotos de Flickr. Para ello utilizaremos el API de Flickr, le pediremos el nombre de usuario y contraseña al usuario y armaremos dicha página. En este tipo de situaciones es en el que Oauth tiene sentido, comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario. La idea es que la aplicación cliente (en este ejemplo nuestra página de inicio) no tenga acceso al nombre de usuario y contraseña del usuario. Dicho de otro modo, Oauth es una metodología para identificación mediante APIs genérica y de implementación gratuita. Si estas cansado de servicios que te piden el usuario de Gmail o Hotmail para proveerte de tal o cual funcionalidad, ya puedes ir viendo por donde puede estar la utilidad de un protocolo como Oauth.

Por supuesto ya hay un montón de estándares cerrados que hacen esto, por ejemplo Google AuthSub o las APIs de Flickr y Facebook, pero la idea tras Oauth es unificar en un estándar abierto de forma que este tipo de comunicaciones entre aplicaciones web (bueno, el cliente puede ser web o de escritorio) no se articulen mediante protocolos propietarios.

Inmediatamente uno piensa en OpenId, pero Oauth no sustituye este estándar para identificación de usuarios, sino que lo complementa. De hecho, los usuarios nunca "ven" nada relacionado con Oauth, situado en el nivel de comunicación entre aplicaciones. De hecho, gran parte de la gracia de Oauth es que el usuario controle a qué datos acceden terceras aplicaciones. Siguiendo con el ejemplo de Flickr, se podría establecer qué tipo de fotos sí y cuáles no desde el servicio proveedor y los clientes no podría obtener nada más.

Como dato curioso, detrás de Oauth están Pownce, Twitter, SixApart, Jaiku, Flickr, Ma.gnolia y Google entre otros, aunque este último parece que no lo soporta en OpenSocial de entrada. Entiendo que el motivo es que no hay una versión final del estándar todavía.

Más información en su sitio oficial, que tiene blog. En español hay referencias en eConectados y La cofa.