Anders Conbere

When I first started playing in the Social Network Portability space I was working on some very light weight social network applications and wanted a way to interact with a global set of users quickly and easily. Right away I discovered foaf and xfn. I was immediately disenchanted with both technologies for what at the time I termed "statelessness", and in some late night discussion I thought about how my IM buddy list captured all the details I wanted from my friends networks, but allowed me to dynamically update it. From that came xmpp-psn, and numerous other projects that have all since failed horribly.

The state of SNP is not the rosy one that is given by the web community. Yes we have XFN, yes we have FOAF and XMPP, and DISO and SIOC. But most all of these technologies have massive flaws. That being said I think there's real hope for both XMPP and FOAF (more on why I'm leaving XFN off this list later).

So getting back to "Statelessness", XFN and FOAF both suffer from being static representations of a social network, both have the ability to describe complex graphs, be pulled real time, and as such aggregated. But the problems arise when a social network decides to make use of this data (say through google's Social Graph API), at this point the data leaves the control of the user and since it's stateless it becomes a "copy" of that data on the social networks network store, and in FOAF and XFN these technologies do not provide the means to communicate new changes back to the original source.

The current method of thinking seems to suggest that each time I join a new social network I'll point them to some canonical representation of my identity (a foaf file, an openID etc.) and the social network will then process the FOAF or XFN data, store the nodes and arcs in their database and connect me via that data to other users in their network. Then they in turn will publish that data. So the current model starts to fall apart at this point, as networks are then forced to aggregate that social data from each other in oder to stay relevant. This results in either having to be smart about caching and networking, or exponentially increasing number of polling connections (presuming we're using http). XFN further exasperates the difference between what's available for the Social Network provider and the canonical definition of the graph (by way of hrefs) as publishers really have almost no way of changing or removing content from that representation once it's been indexed, spread across multiple pages and distributed across the net.

Contrast this now with a technology like XMPP where the roster is stored on a particular server, queryable from any client in the network of federated XMPP clients, and can be adjusted realtime. This means that in order for social networks to stay up to date with XMPP they make a simple call to the users XMPP server and parse the results, and if they have changes they want to make, they can them communicate those changes back to the XMPP server. Looking at the traffic we now are back at a linearly increasing traffic graph, and the complexity of the operations has been reduced significantly. This being said, XMPP has it's own host of issues, not the least of which is it's ability to interact with the web over http, and the complexity of programing api's to communicate with it as it stands today.

It should be clear that the current state of FOAF and XFN aren't really going to cut it for todays social networks. They are great static publish side technologies, but that's not the world we live in with social networks. Social networks are wildly dynamic and they shift with context and need real time awareness. But but FOAF and XFN are doing something great, they are actually getting that data published and out there. Now we need to turn around and look at how those technologies can be made better for the creators of social networks.

So what do we do about it? Surprisingly completely on it's own and unrelated the rdf community has created some technology that I think might be extremely relevant here. It's called SPARQL and you can imagine it as being a simple SQL like query language for RDF stores. This it seems would make an incredible tool for defining the communication methods between hosts providing FOAF data. Now this problem isn't even close to being solved either, but the steps to solve it aren't particularly hard. There have been some interesting extensions to SPARQL that allow for inserts and updates. If we standardize on that as a means of communication then the supplier of FOAF data now needs to provide a means of digesting those SPARQL queries and announcing that they support updates to their FOAF file. Couple this with the work that Dan Brickley's been doing on oAuth bindings for FOAF and you have a powerful tool for not only representing your relationship data, but maintaining the state of those relationships close to realtime.

As for XFN? I don't think XFN is up for the job I don't see any way to repair the problems I've mentioned above with the state of XFN. (If you have one please tell me!)

Today I finished the first working xmpp-psn client, it's a small ruby module, and will let you talk http to a running xmpp-psn server anywhere to do xmpp/jabber. I don't have it in subversion yet, but it should be there soon as I clean up a few things and finish some testing. In all the performance looks to be pretty good, and it works :-D

A python client should be coming soon!

Today I finished the first version of a Django app that lets you build a social networking site on top of Jabber (XMPP). You can find out more about the basics of the project here, but basically it's an http layer on top of a common python XMPP library that lets you do most of the roster management available through XMPP by way of a simple restful api.

The workflow for using it is simple, just install the app into an existing django project, and that will expose the api. From there you can post your jid and password to the /login/ url which returns a uuid and a roster in JSON format for your web app to digest. (note: this is horrible security practice, don't do this in the wild) Now that you have a uuid you have access to the rest of the api, which links to a thread on the sever that keep track of your jabber session.

the following is a list of the supported roster functions:

• disconnect
• roster
• subscribe
• unsubscribe
• authorize
• unauthorize
• remove
• login

I've been spending sometime thinking about one of my primary concerns with social networking tools today, the non-portability of the data you put into them. That is, you spend a great deal of time on any given social networking service discovering, and managing your social network, yet all the work that's done there is in general trapped on that service.

There are some services that have taken a more socially conscious attitude and allow you to export that data. From the look of Leah Culvers blog pownce (and by association probably digg) will be providing a service to manage your social graphs, Geni has a feature that allows you to export the family tree you've created and so on.

The solutions I've seen thus far are varied and there appears to be a lot of work going on in this space to come up with a solutions that works for service providers (facebook, myspace, pownce) as well as users of these services (my friends). Most of what I'm seeing is a kind of mashup of XFN, microformats, openID and scraping of sites. (The pownce solutions is actually a lot better than this in that it relies on a two way communication between the given services providing an actual api for the service to tie into). Other solutions have involved XML exports, or FOAF, but in the end all of these services rely on a static technology(XML) and a web service to manage the source of that XML document that services such as myspace and facebook could tie into.

I feel like these types of solutions are only stop gap measures for a type of problem that begs for a decentralized dynamic approach.

The approach I've been taking is too take a look at what some of the other protocols available on the web already provide for us. In particular I think that most of what people are looking for in terms of a tool to collect and provide social graph data is cleverly handled by XMPP (jabber).

To better understand where I'm coming from here I want to lay out some of the basic problems we're trying to tackle with portable social networking. As I see them they are:

1. a unique identification system: you have to have some way of uniquely identifying members of your social graph. This could be via openID or another uri type structure, or how email/xmpp does it with unique names per domain.

2. an standardized format for defining relationships: XFN, FOAF, or just a list of friends will do. But people need to know what kind of data they're getting back. Looking at how most providers deal with friend data, the most important datum to know is who you recognize as being a "friend"

3. a simple safe web api for requesting this data for use on other networks.

After one tackles those three primary problems the secondary problems are things like:

1. The system should be distributed: This will allow for the easy use and scaling of the system.

2. The system should be defined in a clear open standard: We don't want people to be tied to a particular language or implementation.

given that problem definition XMPP provides for nearly all of those and more. So how does it work?

We use XMPP's existing network, Jabber, to provide a decentralized set of servers for us to use. Each user on the jabber network has a unique id provided of the form xxx@domain.tld, authentication is over SASL and takes place in direct communication to the users jabber server from the client.

The xmpp term for a social graph is a "roster" or buddy list. The roster provides a list of people with whom you have a trust relationship. By requesting a roster from an xmpp server you receive an xml file with a list of trusted users.

So, we as a social networking provider, ask for jabber authentication information at signup, those details are used to request a roster from their xmpp server, which we then use to form a starting social network on our service. Add a friend links or remove a friend links make a call to the xmpp server to remove or add the unique id's to and from their roster, this can either make direct calls to the webservice api or that can be done on the backend. In this way services are easily able to deploy their own xmpp gateway and yet any work done on their network is directly translated into changes in the jabber roster.

What excites me about this solution is that it actually gives something back to the network providers that they aren't getting now, for free. It gives them chat and presence! not only that but it allows users to manage their friend networks in the ways that they are comfortable with now, either through their current network providers (facebook, myspace), or through their im client, etc.