Some challenges in current DataPortability trends

In the last couple of weeks there have been a number of very positive steps forward for Data Portability in general and the DataPortability Project specifically.

These include wins by the OpenID Foundation, the IC report, the DataPortability Report and others.

A couple of trends, though, are causing me a little concern and may require a slight course correction before they spin out of control and fragment, rather than standardize, the ecosystem.

1. Tightly coupled OpenID Implementations

On Plaxo right now there is a ‘Sign in with YahooID’ button. This is effectively an OpenID login mechanism, except to remove the user experience complexity of OpenID, Plaxo has worked with Yahoo to make it easier by creating a direct relationship.

This seems antithetical to the promise of OpenID and could ultimately create another mess of tightly coupled vendor relationships that defeat the purpose of a single sign-on identity that any provider can provide and consume.

A more long term solution must be to improve the generic OpenID user experience or devise an education campaign to help users learn the new login process.

2. Google’s Social Graph API

While revealing an enormous usefulness in the existing XFN and FOAF data out on the web, Google’s Social Graph API also reveals a weakness in current XFN and FOAF implementations. Many users are not aware when XFN data is included around URLs they enter, much less when the URLs are marked as rel=me.

For example when Twitter asked me for my homepage, I didn’t understand that I was asserting a semantic link from Twitter to my blog that Google would later document and carve into stone as part of its implicit global social network in the sky.

As it stands, there is a real concern for user backlash as these APIs start being implemented and users find themselves presented with eerily accurate information about themselves magically appearing on websites without their ‘consent’.

Some sort of best practice text and/or iconography is required around fields that will be marked up with XFN – particularly if rel=me will be used to that users can make informed decisions about the type of data they provide and how it might be used. Perhaps even an opt out checkbox is appropriate.

This is probably a job for the Microformat community to dig into and solve. They should probably solve it quickly though.

3. OpenSocial++

As OpenSocial implementations role out, it’s becoming clear that there is no such thing as a pure OpenSocial container. Each container includes proprietary APIs and extensions that widget developers may choose to use.

Presumably these exist to differentiate each network and encourage developers to write enhanced apps for the environment.

The problem, though, is that developers need to write defensively for each custom API leading us to a place similar to browser compatibility hell. App developers will need to write and test their apps across every Container and will either have to hard code support for special APIs or keep their apps generic and ordinary.

Is this sustainable? Is there a better way?

If OpenSocial is going to be the Write Once, Deploy Many model for widgets, then the OpenSocial team at Google need to find a way to address this concern quickly.