Portable Social Networks, The Building Blocks Of A Social Web
Published on July 1, 2008
Social networks as we know them—MySpace, Facebook, Twitter—each keep identity and personal relationships separate from one another. Every time you join a network, that information has to be duplicated, by hand, by you. It’s a familiar process, but in 2008 we have the tools to break that trend.
It’s inevitable that information has been siloed in the young technologies of the internet, and it’s taken until now to clearly establish the points of commonality between different social tools. In 2008, identity, authentication, and the concept of a user profile can be untethered from proprietary data stores and become an interchangeable part of the Web as HTML itself.
Developers can harness these new, microformat-based technologies to improve their products and contribute back into this open social network. This article explains how Distributed Social Networking works, the benefits already available to consumers, and how developers and publishers can connect up their sites.
The New Social Networking
The Distributed Social Network—or DSN—is the idea of bringing together disparate user information easily and interoperably between social services. It’s often used synonymously with ‘Portable Social Network’, which is a term more focused on moving data between services.
The motivation of DSN is not about being able to ‘dump’ social networks for others. This isn’t about being able to effortlessly quit Facebook and join Bebo. The motivation is to let people use different services with less effort—being able to get set and running with Dopplr and Flickr without having to find friends and contacts by hand every time.
This technology is about surfacing information which is already published. User names, profiles, and contact lists are already out there, buried in HTML. No user is being asked to expose themselves any more than they are; what we’re doing is to make that public information consumable in a consistent manner, to create a better user experience across sites.
In the beginning…
So, the internet.
In the beginning, there was the URL. Many saw that this was good, and in short order there were many URLs. URLs can represent anything at all, but since the very earliest days of the World Wide Web, individual URLs have often represented people. Not a formal, technology-based representation like OpenID, but an ad-hoc, contextual way; personal homepages, .plans, weblogs, and user profile pages, each pairing a URL with a human being.
The internet is full of URLs, and some of those represent identities; one of them likely represents you. But really, all a URL points to is a resource. On the internet, you are a resource; it’s harsh.
Consolidation of identity
Rather than one URL representing one person, that person invariably operates many URLs. The first step of distributed social networking is to consolidate distributed identities together.
XFN is a microformat to link URLs by social relationships. It links between different people (friendships, families and neighbourhoods), but also describes links between different URLs operated by the same individual.
rel attribute on the
a element describes the link between two resources. Using XFN’s
rel="me" pattern allows one URL to claim that another URL represents the same person. A distributed identity can be verified where both URLs link to each other with
So, on my personal site I publish the following link:
<a href="http://flickr.com/people/benward" rel="me">Photographs</a>
Flickr, in turn links back to my homepage:
<a href="http://ben-ward.co.uk" rel="me">Ben's Homepage</a>
Both pages claim the other, so the divided identity is consolidated. It doesn’t matter which URL a parser starts at, it is verified that both URLs represent the same person.
Any number of pages can be linked into an identity through
rel="me". My homepage links to Flickr, Upcoming, and Twitter. Whilst Flickr only links to my homepage, the links are chained together so that my Twitter page is related to my Flickr page, via the homepage.
A more formal online representation of identity is an OpenID, an authentication mechanism. An OpenID is itself just a URL which can be linked to, with
rel="me", and tied into a consolidated identity.
We’re still operating in the cold terms of everything being a ‘resource’. Even in a world before XFN and OpenID, URLs have provided more than just an identifier. The content of that resource provides context about the person who owns it.
Where the URL itself is an identity, the content located at that URL makes up the personality. A blog, an ‘About Me’ page, a list of links; that is the person atop the resource.
Patterns like microformats allow much of this personality to be structured. hCard provides a flexible structured data pattern for a person’s information to be marked up: Names, addresses, avatars, and (in combination with other formats) content. Through the presence of an hCard, no matter how detailed, a personality at a URL can be explicitly marked-up.
This can be in two forms. Either a full, detailed hCard that contains name, contact information, and links to other social nodes of the person (all linked with
rel="me"), or a more minimal hCard that may link to more detail elsewhere.
<address class="vcard"> <a class="fn url" href="/">Ben Ward</a> / <span class="tel"> <span class="type">Cell</span> phone: <span class="value">+44 7123 123 123</span> </span> / <a href="url" href="http://flickr.com/photos/benward" rel="me"> Flickr </a> / <a href="url" href="http://del.icio.us/benward" rel="me"> Bookmarks </a> </address>
<address class="vcard"> <a class="fn url uid" href="/about" rel="me">Ben Ward</a> </address>
Note the use of the
uid property in the hCard, which when used on an
anchor element indicates a URL where a more authoritative hCard can be found (in this case, on the site’s ‘/about’ page).
(Because this hCard is for the person who owns and operates the URL, it’s optimal to use an
address element for the hCard. Keep in mind
address can only be used inline, though.)
Structured data enhances the personality information already published at an identity URL, and creates a profile. Profiles marked up with hCard are reusable and portable.
Always remember that an hCard only has to contain as much information as you you are comfortable sharing. Whilst fields for email, telephone, and postal addresses exist, you should only publish the information that you want to be publicly accessible (a rule that applies regardless of whether patterns such as hCard are being used).
Relationships between people
With individual identities linked through just one of XFN’s values—
rel="me"—the rest of XFN is for linking up with others. XFN has a rich vocabulary, but social networking as we know it only requires three of these values.
A contact is the loosest social link in XFN. It is “
someone you know how to get in touch with”. In practice, this is like ‘following’ someone on Twitter, or adding a ‘contact’ on Flickr.
A more established relationship than ‘contact’. Someone you have active communications with and share a certain degree of trust. In a twist, this is really all that’s required to call someone a ‘friend’ on the internet. As such, ‘Friend’ on Flickr, Last.fm, and so on is best expressed with
kindescribes any family member. Because social networking sites are quite protective of people’s sex and age, they don’t expose the more specific relationships like
kinexists as a catch-all, just as for marking someone as ‘family’ on Flickr.
Social networking services have ‘contacts pages’ and in a decentralised network those still exist, but there can be social contact information embedded in any hyperlink; Wordpress has offered the functionality to include XFN in links on a blogroll for years. When the social network is distributed, those links in your blog’s sidebar contribute. Even linking to a friend from within a blog post can describe a relationship.
Working with these relationships
Wordpress, Flickr, MetaFilter—huge names on the web—are all publishing XFN relationships. Following the advice and instruction of this article, your pages can be part of this grand distributed network too. Like all microformat-based techniques, the cost of implementation is extraordinarily low; really, it’s all just richer markup.
Where it gets very interesting is in consumption.
So many address books
Address Books stagnate; the database of names, numbers, and addresses you enter into your telephones and email applications are entirely disconnected from the owners of that information, the contacts themselves. When your friends update any piece of information, the notification mechanism is manual. An email or SMS to inform you that their number has changed; assuming they remember to include you in their bulk mailing.
Facebook has given a glimpse of the way things should work, since the user base is so large and broad it has become a de facto address book for many people. Profile details are updated by the owners, so are up to date for as long as those people use Facebook. Friends get those updates instantly, because the data is all sourced from the same central place.
However, it’s a closed system. Information is locked away from external applications. You can’t synchronise your Facebook friend’s telephone number to your mobile phone without an exhausting workout of copy-and-paste, and you still need to watch for changes yourself.
What a distributed social network enables is for this sort of information to be sourced from the owners, from anywhere. Your address book can point at my website, and synchronise my contact record with the hCard that I control. A technology like OAuth or OpenID whitelists can be used to protect my more sensitive information—addresses and telephone numbers—from public eyes and restrict it to trusted people.
In the distributed model, people are represented with a URL, and from there, little more is needed for those people to share structured profile information from their own source.
So many profiles
The address book is focused on pulling contact information from distributed sources. But once published and consolidated, that information can be used to fill and synchronise the information displayed in most social profiles across multiple services. Names, nicknames, descriptions, and avatar images are all common fields that can be described with hCard.
Publishing hCard in one place allows that public profile information to be reused elsewhere. Users are saved the hassle of re-entering their details over and over, and when they update a profile the information can be synchronised across the web.
So, when building a social application, take the user’s URL first as they’re signing up (that might be an OpenID, too). Once you have the URL, use a little Ajax and load it in the background; use a parser such as hKit in PHP, or AUMP in Python, to parse the URL and if an hCard is found, save the user the trouble and pre-fill their profile information. If anything gets filled in that they don’t want displayed on your site, they have the option to blank it out.
When their profile is saved, note their URL, note any fields they’ve chosen to censor on your site (so as not to inadvertently refill it later), then schedule a script to periodically update the fields they’ve left filled in.
Ueli Weiss has written a great example of pre-populating profiles from hCards. You can try out his profile importer demo to get an idea of what’s possible.
So many contact lists
Along with re-entering personal information, the other key components of a social network are the social relationships themselves. XFN makes them parsable, and allows a new social network to find existing contact and friend relationships, matching other users on the network and offering to link them up.
The days of registering for Twitter and manually wading through the user database, searching for individuals, can be ended by XFN. Social networks can attempt to parse relationships from specific sites—iLike could parse Last.fm to find social relationships for the same subject matter, and vice versa—or could use an aggregator like Google Social Graph to find relationships from all over the web.
This kind of application is already being attempted on a site-specific basis. Brightkite, a location-enhanced competitor to Twitter, uses the Twitter API to pre-populate contact lists for migrating users, but they could just as feasibly consume the hCards from Twitter, and allow their service to be pointed at any hCard publisher on the web to discover friends.
Aside: A note about terrifying your users
Be under no illusion, this is a new concept. Users aren’t going to expect their information from public sources appearing in different places, and at first it’s a very scary concept. Most won’t really appreciate that information on the internet is public. Communicated correctly, they will appreciate it, but at the bleeding edge you need to be very sensitive.
It’s best to make clear when pre-filling a profile where you got the information from (e.g. ‘Found your nickname on Last.fm’, ‘Found your avatar on Flickr’, ‘Found your Flickr profile on your homepage’). It reassures users that the information is sourced from familiar places, and if they see something uncomfortable or outdated, informs them of where to go to update it. Data stagnation is a problem as old as the first social profile on the web, and consuming it is going to have a large benefit through making users aware of what is published about themselves.
Contact lists are the same. People keep their friends segregated. Last.fm contacts are collected around musical interest, so a user won’t want all those people added to a Flickr or Twitter network. When parsing a contact list, again show the source (or multiple sources; where contacts show up over and over you can likely promote them as the most likely candidates for friendship). Critically, allow user control of who gets imported into your system. When synchronising, don’t automatically add new friends into a site, ask the user to add that friend. Use XFN for discovery, not for the automation of someone’s social pool. Don’t ‘steal’ their contacts.
Dynamically aggregate content
Facebook brought the concept of a multimedia life stream to the masses, combining photographs, blog posts, and status updates into a single information feed. It reinforces the Facebook walled-garden by providing all the activity information about individual people in one place. In the distributed world, there’s one activity stream for each site: Twitter activity, new Flickr photos, event attendance on Upcoming, or scrobbling on Last.fm; four separate streams. What they have in common are feeds, usually some version of RSS or Atom.
FriendFeed tries to do this, but it in itself is a centralised social tool, requiring your friends to be a part of it (or at the least, manual configuration of each friend who isn’t a member).
Starting with a single user, their participation in social networks is indicated through
rel="me" links; their consolidated identity. From there, contact lists can be pooled together, and those contacts’ identities consolidated too. At each of those contacts’ places on the internet, blogs, Last.fm, Flickr, or Upcoming.org profiles, there is a feed.
An application like this can use these very simple links between pages to dynamically assemble a list of feed subscriptions, and intersect the content. Grouping content together ala Facebook (‘Colin posted five photos’, ‘All but one of your friends changed their profile picture again’) is an aesthetic task for the application, but once assembled, the entries can be powerfully filtered and sorted.
Hiding or de-prioritising stories from particular social sources is easy enough, but since feed entries are often categorised and tagged too, tools can go beyond filtering by type, and actually enable more complex interactions with social content. For example, with feeds as the transport, content can have location (through GeoRSS and the geo microformat) and be filtered to information created in particular locations.
It’s at this point the core of the decentralised social network is exposed, and it’s an elaborate game of ‘join the dots’. The relative simplicity and occasional crudeness of the technology that powers the internet is what has made it work so effectively thus far, and the open social layer is no more complicated than it needs to be.
What to do right now
Much of what distributed social tools enable hasn’t been built yet. Can you just add a URL to an address book and have it stay in sync? No. Can you effortlessly share contact lists around in the way described in this article? Not really. But the technology that enables this to happen is there now.
At low development cost you can enhance your pages with microformats to hook them into this grand social net. You can use parsers in a variety of languages (see microformats.org/wiki/parsers) to start consuming hCards in your registration processes. You can discover relationships from single sites with simple XFN parsing, and point at other sites as you grow. You can use Google’s Social Graph API to quickly query an index of XFN relationship data from across many sites.
Just use the URL
http://socialgraph.apis.google.com/lookup?q=http://ben-ward.co.uk&pretty=1&fme=1 to return all the
rel="me" links for my domain, and the following to establish friend URLs:
links from ben-ward.co.uk to friends.
links to ben-ward.co.uk to friends.
Those URLs require no registration or API keys, they just work and return JSON that you can consume in your applications.
The foundations are in place, and you can build these tools today.