links for 2008-04-07

URLs aren’t just for web pages

We’re all use to using URLs to point at web pages but we too often forget that they can be use for other things too. They can address any resource and that includes: people, documents, images, services (e.g., “today’s weather report for London”), TV or Radio Programmes in fact any abstract concept or entity that can be identified, named and addressed.

Also, because these resources can have representations which can be processed by machines (through the use of RDF, Microformats, RDFa, etc.), you can do interesting things with that information. Some of the most interesting things you can do happen when URLs identify people.

Currently people are normally identified within web apps by their email address. I guess this sort of makes sense because email addresses are unique, just about everyone has one and it means the website can contact you. But URLs are better. URLs are better because they offer the right affordance.

If you have someone’s URL then you can go to that URL and find out stuff about that person – you can assess their provenience (by reading what they’ve said about themselves, by seeing who’s in their social network via tools such as XFN, FOAF and Google’s Social Graph API), you can also discover how to contact them (or ask permission to do so).

With e-mails the affordance is all the wrong way round – if I have your email address I can send you stuff, but I can’t check to see who you are, or even if it is really you. Email addresses are for contacting people they aren’t identifiers; by conflating the two we’ve gots ourselves into trouble because email addresses aren’t very good at identifying people nor can they be shared publicly without exposing folk to spam and the like.

This is in essence the key advantage offered by OpenID which uses URLs to provide digital identifiers for people. If we then add OAuth into the mix we can do all sorts of clear things.

The OAuth protocol can be used to authenticate any request for information (for example sending the person a message), the owner of the URL/OpenID decides whether or not to grant you that privilege. This means that it doesn’t matter if someone gets hold of an URL identifier – unless the owner grants permission (on a per instance basis) they are useless – this is in contrast to what happens with Email identifiers – once I have it I can use it to contact you whether you like it or not.

Also because I can give any service a list of my friend’s URLs without worrying that their contact details will get stolen I can tip up at any web service and find which of my friends are using it without having to share their contact details. In other words by using URLs to identify people I can share my online relationships without sharing or porting my or my friend’s contact data.

You retain control over your data, but we share the relationships (the edges) within our social graph. And that’s the way it should be, after all that all it needs to be. If I have your URL I can find whatever information (email, home phone number, current location, bank details) you decide you want to make public and I can ask you nicely for more if I need it – using OAuth you can give me permission and revoke it if you want.

Photo: Point!, by a2gemma. Used under licence.

Social relationship portability

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.

Galaxies Forming

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.