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.

Foo Camping

I’ve just published a short piece on my recent trip to San Francisco and the O’Reilly Foo Camp over at the BBC Radio Lab’s blog.

It was my first trip to San Francisco and I loved the city (you can see my photos on Flickr). But I was also struck my how meme friendly the place is. I guess that’s not that surprising – it’s a relatively small city with a high density of tech companies in and around the bay area, but none the less it does appear to be a good place for tech memes to arise and flourish. One reason why that corner of the world produces so much innovative technology?

Anyway below is my blog post as published on the Radio Lab’s blog.

SGFoo08

“I’ve recently returned from a very enjoyable and educational trip to California where I was honored to be invited to attend the Social Graph Foo Camp. Although I do have to say that while I found the whole thing very exciting I was also, at times, left realising just how far behind some of the conversations I have become, it really is amazing how rapidly the issues and technology within this space are developing – and that’s in the context of a fast moving industry.

It was, however, clear that the really big issues are social not technological: user expectations, data ownership and portability. Although a key piece of the technology puzzle in all this is the establishment of XFN and FOAF which are going to play an ever increasingly important role in glueing different social networks together. And with the launch of Google’s Social Graph API (released under a Creative Commons license by the way) data portability is going to really explode; but with it expect more “Scoblegate” like incidents.

But the prize for getting this right are great, as illustrated by this clip of Joseph Smarr of Plaxo presenting on friends list portability and who owns the data in social networks.

For my part what I took away from this and other discussion is that although on the surface moving data between one social network and another is no different from copying a business card into Outlook people’s expectations make it different. 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. Google’s Social Graph API will make it easier – but there will be a price, as Tim O’Reilly points out:

“Google’s Social Graph API… will definitively end “security by obscurity” regarding people and their relationships, as well as opening up the social graph to “rel=me” spammers. The counter-argument is that all this data is available anyway, and that by making it more visible, we raise people’s awareness and ultimately their behavior.”

Tied to all of this, of course, is the rise of OpenID, the open and decentralized identity system, and OAuth an open protocol to allow secure API authentication between application. Both of which appear to be central to most people’s plans for the coming year.

So what were the other highlights? For me I’m really exited by Tom Coates and Rabble’s latest Yahoo! project: Fire Eagle; which allows you to share you location with friends, other websites or services.

You can think of Fire Eagle as a location brokerage service. Via open APIs other people can write applications that update Fire Eagle with your location so that further applications that can then use it. So for example, someone might write an application that runs on your mobile that triangulates your position based on the location of the transmitters before sending the data to Fire Eagle. You could then run an application on your phone that let you know if your friends where near by, what restaurants are in your area or where the nearest train or tube station is.

Obviously what Fire Eagle also provides is lots of security so you can control who and what applications have access to your location data. I can’t wait to see what people end up doing with Fire Eagle and I’m hoping that we can come up with some interesting applications too.

Finally, XMPP, which I have to say caught me a bit by surprises. If you’ve not come across it before XMPP it’s a messaging and presence protocol developed by Jabber and now used by Google Talk, Jaiku and Apple’s iChat amongst others (with a lot more clients on the way if last weekend was anything to go by).

XMPP is a much more efficient protocol than HTTP for two way messaging because you don’t require your application to check in with the servers periodically – instead the server sends a signal via XMPP when new information is published. And there’s no need to limit that communication to person to person – XMPP can also be used for essentially machine-to-machine Instant Messaging which means you have real time communication between machines.

So based on last weekend’s Foo Camp it looks like XMPP, OpenID, OAuth are all going to be huge in 2008, Google’s Social Graph API and related technologies (FOAF and XFN) will result in some head aches while people’s understanding and expectations settle down but it will be worth it as we move towards a world of data portability.”