Federating Social Networks – An Introduction
Last Saturday I participated in the Federating Social Networks workshop organized by the fine peeps of Mediamatic (Lab), most especially Ralph. Reduced to its essence, the goal of FSN is to enable websites (“social networks”) to stream data to each other. Rather than pulling data in via feeds and API calls, websites can push data out over an XMPP stream.
One reason social networks may start federating is that feeds don’t scale. Some examples:
Blaine Cook of Twitter, who flew over from SF to participate in the workshop, noted that Twitter is getting hundreds of millions of requests through the RSS feed. Apps like Twitterific are limited to one request per client per minute, which is not enough for them to live up to their potential. For Twitter to be able to push tweets to apps such as Twitterific would save them a lot of server load.
Jaiku has been blocked a number of times for hitting sites like Last.fm too hard, just to pull in songs. Since Jaiku tries to aggregate a lot of feeds into a lifestream, it’s hitting sites such as Last.fm, Flickr and Twitter constantly. Reversing the aggregation by having Flickr notify Jaiku when a new photo is posted would a) enable Jaiku to display the photo instantly, and b) save Flickr from unnecessary polling.
Of course, federating will have its effect on the business models of these sites as well. For Twitter, one upside of federating is that there’ll be more development around it. Twitterific will be real-time, and will be able to provide many more features. Jaiku will be able to display tweets as if they were jaikus. This may mean that more people start using Twitter, without having to lose their contacts on Jaiku. But, if Jaiku also starts federating, Twitter will be able to display jaikus as if they were tweets. More people may start to use Jaiku rather than Twitter!
What this really means is that boundaries between services start to dissolve. The services will have to be more open, and without lock-in will have to do a better job than its competition. Which, of course, is only good for the end user. And not opening up will only make the services more vulnerable to being out-opened by upstarts.
The protocols to achieve federation are already here today, and Mediamatic is committed to actually get it working. In fact, Mediamatic is in a rather special position where they run several social networks which could greatly benefit from federating, and have obtained a government grant to build a federating system. With Twitter and SixApart also involved – David Recordon of SixApart also flew over from SF – federated social networks have a pretty good chance at becoming reality.
We live in interesting times!
What you’re mixing up (as was also done during the workshop) are the questions of scalability and interoperability.
If we can get away from a model of polling feeds to a push model, that will definitely enable new functionality for those that can use it. But in the mean time HTTP will be becoming much more performant by the increasing popularity of non blocking webservers. This will give HTTP a still longer lease on life. These scalability problems are only an issue with the biggest of sites. It is only moderately interesting to model smaller along those problems.
The real issue is to provide current sites with the specs for the payloads and semantics. I don’t care if they’re delivered using HTTP or XMPP (implementation details). Sites need to be enabled to interoperate to a level they are comfortable with and keep their users in control of the situation. I’m afraid while scalability seems to be solved technically, we have only scratched the surface of the greater problem.
Alper | 10 December 2007, 23:42 | link
As a user of multiple social networks I would love for this to happen quickly, I hate having to open multiple browser windows to check and keep up with changes on myspace and twitter and everything separately, I’d love to have on page that was able to accept the push from multiple sites.
Joe | 25 March 2008, 01:50 | link