The Case for Decentralized Social Networks
Oct 03, 2007
This article was originally written October 3, 2007 and published here before OpenSocial was announced. With this blog post, I'm moving it to my blog to avail of features such as commenting and cross-linking with other related posts. I have not edited it since the original writing; if I do, edits will appear as updates marked as such.
Social networks are currently walled gardens: you need an account on multiple social networking sites to be able to interact with all your friends. This article makes a case for opening up the core protocols that define person-to-person interaction (decentralized networks) and various aspects of your public personality (decentralized applications). It is possible to use a few well-known semantic Web protocols and microformats to break down the walls and make the Internet a true social network.
Social networking Web sites are currently walled gardens. If you're on MySpace, you cannot communicate with Facebook users or Orkut users. Although the features provided by most sites are comparable, if not equivalent, one must have an account on each of these sites to interact with members from that community.
The Motivation
That is not how social networks work in the real world. I do not need to be a citizen of a country or a follower of a religion to converse with the members of that country or religion, respectively. OK, this is a far-fetched analogy, but consider email.
The Evolution of Email
Before email as we know it today was in wide-spread use, the earliest way to send a message to anyone using a computer was simply to drop a file in their home directory. You could thus only send a message to users of the same computer as you. Ray Tomlinson came up with the idea of addressing users using the "@" sign, so email could be sent across computers. In the opinion of Jon Postel, this was a nice hack that finally evolved to an IETF RFC.
Today, we are able to address email to anyone on any network that's connected to the Internet. Their ISP, or operating system, or mail transmission agent (MTA) or mail user agent (MUA; commonly referred to as a mail client) has no bearing on whether they will receive our email or not. The diversity in the email ecosystem allows me to receive, download and view my email in exactly the way I want.
Fast forward to Instant Messaging
Instant messaging evolved similarly, with ICQ, AOL, Yahoo!, and Microsoft all developing their functionally-equivalent, but non-interoperable protocols for essentially the same task. You had to have an account with each of those providers to be able to talk to their users. Along came XMPP and Jabber, followed by the development of an IETF RFC for instant messaging, which has now found support in commercial products such as Google Talk. XMPP does not require users to have accounts on multiple servers; if you have an account on one XMPP server, you can chat with any user on any other XMPP network (provided other prerequisites such as authorization are met.)
Why this makes sense for Social Networking
Social networking is no longer one of the fringe activities on the Web. There are several Web sites that purportedly do the same thing (and I'm too lazy to list them all.) The point is, social networking is now becoming a conduit rather than a destination. Much of our online time is spent on social activities, and the importance of individual users and their individual contributions taken together is increasing.
So what would it look like?
A decentralized social network would let users sign up at whichever Host site they prefer (just as you can sign up with any email provider today.) They would be able to participate and interact with users of any other such Host site, with no additional signing up to do. They would be able to create a profile that best reflects their motivation in signing up: a college student may sign up at a Host that allows him to display his classes and academic interests, while a professional may choose a Host site that emphasizes her skills and experience. Applications running on any Host site will have access to the Friends List of the user account they are running under, even across Host sites. A user's profile may even be fragmented across multiple Hosts, with each Host hosting a particular aspect, or type of content for the user.
Advantages for Users
- You don't have to sign up at multiple sites.
- You can choose a Host site that best suits your personality. If you like a casual, "explosion-in-a-media-factory" look, sign up for MySpace. If you prefer a more professional look, go for Facebook. If you want to expose more professional data than personal data, Linked-In is your Host. If you would like to express your affiliation with your company or non-profit, use their Host site as your primary home.
- If none of these suit you, just roll out your own Host site that hosts exactly one profile: yours. That won't prevent you from being part of the larger social network.
- Since individual Hosts manage their user's profiles, privacy can be controlled better. You will retain the choice to pick a service that best matches your privacy expectations.
Advantages for Developers
- When a new social networking site announces their own API and protocols, developers won't have to scamper to port their existing app to it. They simply continue hosting it themselves, and the newcomer Host will simply talk the same language out-of-the-box.
- Developers will also have the flexibility of tailoring their interface whichever way they want — they will not be required to adhere to the strict interface guidelines of individual sites.
- For those that heavily rely on eye-balls and advertising, they can continue to host their own content, not subject to a third party's terms of services.
- Expert users may choose to develop apps for themselves. These one-offs will be easy to integrate with that particular user's profile.
Advantages for Hosts
- Host sites will be able to position themselves in a market better, and distinguish themselves from other offerings in a better way than existing sites can.
- The network effect will no longer be the dominant reason for users picking one social networking site over another, and such sites will have to compete on real features and good design, rather than simply "because all my friends are here".
- Closer ties between users and hosts will enable them to tailor their services to the particular class of users they attract.
A Change in Philosophy
A few things will need to be re-thought, because, in a decentralized network, there are better alternatives to existing ways of doing things.
Disseminating and aggregating specialized content
We have seen specific websites and companies excelling in managing different types of data. Flickr specializes in photos, YouTube in videos, Blogger in blog posts, Twitter in one-line "twits". All-purpose sharing websites such as Facebook also let you upload and embed all these types of content. What is the use of duplicating this content on each individual social networking site?
In a decentralized network, my blog could stay at Blogger, my photos on Flickr, and my videos on YouTube. My personal profile is simply an aggregation of these multiple aspects of my personality. What's more, to design my own profile, I could just pick and choose the "modules" I want from a palette of available syndication options. (In fact, my own website is already designed like that: content you see here is aggregated from Twitter, Flickr, and FeedBurner, plus a few hosted pages.)
Developers can concentrate on what they do best, and outsource the rest of it to experts in individual areas. Photo album designers will not have to reinvent Flickr, and video distributors can simply leech YouTube's bandwidth for their hosting.
Profile information can be mashed up
A user's profile information can easily be mashed up for quick one-off applications. For example, if I need to create a list of all my friends from a particular group to print greeting cards, I do not need to write an application, submit it to Facebook and wait for their approval. I simply deploy it to my own Host's server and get done in the time it takes to write "SELECT * FROM Friends WHERE Group = 'christmas-cards'" (oh, and I would totally pick a host that provides a SQL interface for social data!) I can have an address book that integrates with my web-based email client, that maintains an updated list of email addresses of all my friends, of course pulled from their individual profiles.
Rethinking privacy and authorization
Authentication is easy (we'll look at that soon.) Authorization is hard. But this is a problem that should be easy for public-key cryptography to solve. I'm not a cryptography expert, so anything I say here will be wrong. But I trust that if the experts put their mind to this, it shouldn't be too bad to solve without having Alice, Bob and other alphabet-soup-inspired characters to make all their keys public.
Enhanced Search
To some, this may sound like a gross invasion of privacy, but in fact, deciding what information should be public, and making that publicly-accessible information searchable, are two different problems. Privacy gate-keepers at each Host will decide what content to make publicly accessible. Once that decision has been made, all the major search engines can index the public information (without having access to any of the private stuff.) Google made the Web searchable. A search engine for The One Social Network will make the world's population searchable.
The Ground Work
A quick analysis of what's required to make this happen makes us realize that much of the groundwork has already been laid.
Representing People and Relationships
The chief contribution of the recent boom in social networking is the recognition of the Person as a first-class entity on the Web. Earlier, the only way to represent a person on the Web was via her home-page. But that, too, was a static representation, largely disconnected from the activities and evolution of that person.
A recent push towards including semantic markup in Web pages has led to the development of microformats, a light-weight method of marking up entities within Web content in terms of loosely defined formats that do not interfere with the already-existing presentation duties of HTML. There is the hCard microformat defined for representing a person. The XHTML Friends Network establishes a format for indicating relationships among individuals on the Web. A lot of users and Host sites have made their pages XFN-Friendly, i.e., they have added semantic markup to the lists of their friends to indicate relationships.
Representing Activities
Blogs and twits have emerged as easy ways for people to broadcast their activities to whoever is ready to lend an interested ear. There already are standards that help people share these activity logs in standard formats: Atom and RSS.
Representing Personal Information
Again, microformats have been defined for such diverse things as user-posted reviews, calendar entries, résumés, addresses, geographical location information, with a whole lot of other discussions in progress. The mother of all social networking artifacts, tagging, has also been microformatized.
Communicating Across Diverse Websites
Many sites these days are opening up their APIs for external applications to access and modify users' data over the Web. SOAP, XML-RPC and other, more formal protocols have given way to REST (Representational State Transfer) as a light-weight software architecture for distributed systems. With RESTful websites, it is easy for independent applications to modify data stored on servers: examples include Google's GData APIs for many properties, Flickr's API for accessing photos and metadata, Twitter's API for posting twits, and many other services.
Distributed Authentication
Systems such as Open ID are emerging as viable standards for truly distributed authentication and identity management. There is no reason why an OpenID-based system cannot be used for the Network We Talked About. If we throw in the ability for Hosts to share authentication lists, that would make all Hosts available to all Users, and the question of having to "pick" a particular host may be moot.
What's Missing?
Communication Protocols for Posting Messages Across Hosts
REST is here, but it only defines the transport architecture. A RESTful communication protocol will have to be developed for users to be able to post messages to other users on other Hosts. Nothing monumental, but just one thing that needs to be done.
Representing Groups Across Hosts
Groups of users will need a way to be recognized across Hosts. A simple way of doing this would be a naming scheme that stays unique across the network, much as Usenet groups have been. A lot of the lessons learned from the design of Usenet can be used here, because today's social networks are much similar to Usenet, with a few other goodies thrown in.
Current Efforts
Although we are far from this vision, some sites (mainly Facebook) seem to have started on this path. The Facebook platform was a unique step in allowing developers to access users' profile information. Though, Facebook still is a walled garden. In part to increase traffic, they also have taken baby steps in making users' profiles available to search engines. MySpace profile pages are still very un-crawl-able. Flickr, Upcoming, and other Yahoo! sites use microformats extensively. Facebook provides RSS feeds of user activity.
Although these are steps in the right direction, they are not enough. Hopefully, we will reach a critical mass of social networking sites that adopt an open social network policy. Till then, you can find me at my many online haunts.
