I think most social networking sites get data portability wrong – because they copy your contact data from one system to another. And in doing so often end up spamming your friends with ‘invites’ as well as leaving you with the headache of having to maintain your contact details in lots of different places.

The problem is that just because you have someones contact details, that doesn’t mean that they will want to join every service that you want to join and visa versa. You don’t want to port all your contact data from one service to another; you just want to know when your friends also join a service so you can connect to them.

It can also be argued that data portability can create issues for users. As I’ve discussed previously, at the recent Social Graph Foo Camp there appeared to be consensus that people don’t (yet) expect the data they enter in one site to suddenly appear in another. But they do expect to be able to easily find their friends within a new network. And as noted by Robert Scoble in his conversation with Dave Morin, head of Facebook’s application platform:

… if a user wants to delete his or her info off of Facebook. Today that’s possible. But what about in a really data portable world? After all, in such a world Facebook might have sprayed your email and other data to other social networks. What if those other social networks don’t want to delete your data after you asked Facebook to?

Or

Which of your data is yours? Which belongs to your friends? And, which belongs to the social network itself? For instance, we can say that my photos that I put on Facebook are mine and that they should also be shared with, say, Flickr or SmugMug, right? How about the comments under those photos? The tags? The privacy data that was entered about them? The voting data? And other stuff that other users might have put onto those photos? Is all of that stuff supposed to be portable?

Now I should say up front that I don’t completely buy into Dave’s arguments – for starters they smack of FUD – but that doesn’t mean that there’s no merit in these arguments nor that there aren’t issues with data portability. Copying your entire social graph between different systems can’t be the way forward. As Simon Willison puts it:

I think data portability is the wrong framing—moving data between sites is really hard. Importing social relationships between sites is much more viable (hence my interest in social network portability). Also, the complaints about systems sharing e-mail addresses are neatly addressed by using OpenID as the GUID for a user instead.

A couple of sites spring to mind that I think are getting much closer to the answer: Dopplr and Fire Eagle. Dopplr helps travellers meet up with each other by showing when your friends’ travel plans coincide with yours. Fire Eagle is a service that acts as a geolocation brokerage service – tying together applications that provide geolocation data (mobile phones, GPS devices etc.) with services that consume such data (like Dopplr).

Dopplr doesn’t try to port your address book into it’s own database instead it uses XFN, Google’s contacts data API and Yahoo’s Flickr Auth to find existing Dopplr users you already know on Twitter, GMail and Flickr respectively. In other words Dopplr only imports the social relationships that already exist.

Fire Eagle doesn’t even try to import your social graph. Instead it snuggles into it’s own niche by adding specific functionality to existing services, giving you the ability to share your location with sites and services online. This is very smart, because it means Fire Eagle can focus on what it does best (sharing your location in a secure fashion) and not on what others do best (telling people, you know, which city you are travelling to; sharing photos with your friends; telling folk what you’re up to etc.).

This differentiation strategy – focusing on what you do best and making it as easy as possible for others to integrate with your service – points the way to a possible future where you can plug services together extending the data and functionality available to you. What would this look like? Well one way of cutting it would be:

• Online services either provide functionality or data that can be plugged into your favourite social networking site; or functionality that lets you manage your social graph’s relationships (similar to Dopplr) – all mediated via OAuth or similar.
• Everyone in your network jointly owns the graph – and this is what we should focus on making portable so that if someone you know joins a service you are using then you get to know.
• You should manage your identity and personal data. OpenID is the obvious way of doing this and would mean that your details could be managed in one location and independent of any given service (like Facebook) although of course these sites could also act as OpenID providers.

Obviously you own your resources – your photos, documents etc. and you should always have the right to move these to other services. But you should also be able to connect your social graph to these resources – should you wish to – as Dopplr have done with Flickr. Dopplr doesn’t provide a photo sharing feature – instead it integrates with Flickr so your photos are stored with Flickr but accessible via Dopplr.

Taking this approach not only places you in control of your data – so you won’t get into the problems Dave Morin highlights above but it’s also good for competition.

Photo: Galaxies Forming, by Cobalt123. Used under licence.