OpenID and Social Networking

3rd Dec 2006

I'm sure I'm not the only one that gets grudgingly dragged into these social networking sites, and then spends all his time while using them plotting ways to break out of the walled gardens and turn the whole web into one big social network. It's where my mind wanders when confronted with most good ideas: This thing's great, but now how can I build apon it to make something even more great? The answer with walled-garden social networking is that I can't. Is decentralization the answer? Is it even feasible?

I sat down and made a list of some of the things social networking sites do:

Maintain friendship relationships between people and other entities such as music groups

Provide a means for people to send messages as well as virtual slaps, pokes, snogs and god knows what else to one another

Provide special interest groups to put people of like interest in touch with one another

Allow users to find other people by various criteria such as location, school attendance, age, favourite TV shows, …

Provide privacy features for all of the above so that people can share with their friends without sharing with the world

Provide some form of aggregation for all of the above so that users can see at a glance what their friends are doing

Social networking sites come in many shapes and forms, from straight-up profile sharing and stalking (MySpace, FaceBook) to sites where the social networking is secondary to some other task (LiveJournal, Last.fm, Vox and even Slashdot). Once thing that they all seem to have in common, though, is that there's always some kind of page that represents the user. That page, by virtue of being on the web at all, has a URL. In that sense, then, we already have the basics required to adopt OpenID: make the URL of the user's page an OpenID identity URL. This, in combination with each site also accepting OpenID logins, gives the framework on which much of the above can be built.

With authentication out of the way, we can also declare one item on the list solved: private messages between users — including all of that crazy slap-poke-whatever business — is easy. Plenty of sites are already allowing both private messages and public comments with OpenID Authentication, the spam problem notwithstanding.

Maintaining friendship relationships seems simple on the surface. We can “just” store RDF-style relationship triples between one URL and another. Creating these relationships in the first place is trickier, but one analogy that springs to mind is the Jabber roster. The basic principle behind the Jabber roster is that a relationship can either be unidirectional or bidirectional; a unidirectional relationship can be set up with no co-operation from the other party, but you miss out on certain abilities such as being able to see whether the other party is online. A bidirectional relationship is created by first creating a unidirectional relationship and then sending a subscription request to the foriegn party. The foreign party can then reciprocate to complete the connection. It's simple and it works.

This process could, in fact, be done with just OpenID auth on the site where your friend's profile is hosted; just edit your own profile page to say you are friends with the other person and then go to the other person's profile page, sign in with OpenID and make the friendship request. It'd be nicer if this could be presented to the user as a single step, though: the process of adding the friend to your own profile automatically initiates the friendship request to the other site. This requires your home site to act on your behalf, so a mechanism is required for your home site to make a request to a foreign site while proving to the foreign site that it has permission from you to do so. How can we do this? One possible answer is OpenID Exchange.

OpenID Exchange is, right now, my little baby. It's an evolution of my much older proposal OpenRPC. The idea here is to provide a transport for one site to make some arbitrary HTTP request to another site while the user observes and approves the transaction. Using OpenID Exchange as a foundation, we can define a simple HTTP-based protocol for initiating and responding to friendship requests.

When you add a new friend on your home site, behind the scenes an Exchange request will be set up; your home site will then redirect you to an endpoint at the foreign site, where the foreign site will authenticate you using standard OpenID authentication and then ask you to confirm that you wish to send a friendship request. Once you've confirmed that you do, the foreign site will redirect you back to your home site. Your home site will then, again behind the scenes, send a request to the foreign site to confirm that the request process was successful. The same process can then be used in reverse when your friend at the foreign site accepts your friendship request.

Aggregation of content from your friends is a thornier issue. If all content were public, we could just use RSS or Atom feeds and declare this a solved problem. However, in reality there are lots of people who — quite understandably, I think — wish to share only with people they know. This is evidenced by the popularity of the privacy and security controls offered on every single successful social networking site. The problem is that aggregation is at odds with privacy: in order to build some kind of aggregate newsfeed, it is necessary to pull all of the data into one place. That place will presumably be my home site.

Aggregation at my home site requires a trust relationship not only between me and my friends but also between my friends and my homesite, since the homesite is in a position to compromise any data it has obtained on behalf of its users. This is a tricky issue whose solution is not obvious to me at the moment. A workaround is to aggregate the data on my own computer using a desktop aggregator, but that is unfeasible for most users who will not wish to install software on their computer just to take part in social networking.

The finding of users seems like a difficult problem on the face of it, but we already have mechanisms for locating web resources: search engines. In the presence of appropriate machine-readable metadata, there's no reason why more focused search engines could not be developed — possibly on the back of general-purpose search engines — that search for people rather than for web pages. Given the open and decentralized nature of this approach, a likely result is a collection of novel tools for matching people with one another in various ways.

I've not managed to solve every item on my list here, but I think this a good start. Given the popularity of social networking I think it will be of benefit to a large number of people to figure out solutions to some or all of these problems, and I think OpenID Authentication and Exchange are just the foundations we need to do it.