Skip to content

-->

How to build a distributed social network

There has been a lot of recent interest in projects that aim to replace big, centralized social networks (like Facebook, Xanga and LinkedId) with decentralized, open alternaives that give users greater control and choice. It's interesting to wonder if they will succeed, and how it might be done.

Some notable efforts include Diaspora which is getting lots of interest following a highly successful funding drive on Kickstarter; Appleseed which is attracting lots of developer activity; GNU Social and many others which you can berate me in the comments for not mentioning :-)

A plethora of protocols already exist to serve the needs of an open social network, including XMPP (the basis for Google Wave), OAuth and OpenId for authentication, and OpenSocial, and for data transfer we've got a huge choice: XFN, JSON, ReST, SOAP, RSS and ATOM, to name a few.

Uptake: users, experimenters and developers

It seems that all the parts are sitting there, waiting to be assembled together into something that everyone will use. But it's not that simple.

A distributed social network (DSN) will face two main problems before it can begin to rival the big closed social networks: user takeup and install base. The first will happen when people see a genuine benefit of using the DSN over the walled garden they currently use. It won't be enough to simply mimic the features of Facebook, Myspace or LinkedIn. At the end of the day, ends will matter more than means but there are ways that a DSN can take advantage of its architecture to do things that closed systems can't (more about that later).

As for privacy, and a DSN will have to provide simple, reliable control over personal data. A system which bewilders users with lots of fine-grained data control options will not meet this need. People will naturally assume a level of privacy similar to email.

The install base will make or break a DSN. It would be wise to follow the example of Wordpress, and make it extremely easy to setup, install and hack about with. Wordpress succeeded by leveraging the popularity of PHP and MySQL which have enough developers to rival the People's Liberation Army. Today, scripting languages such as Python and Ruby are in a similar position to PHP 10 years ago. VPS's are going the way of shared hosting 10 years ago. You can get your own virtual Linux server with a decent spec for under 20 USD - I have one with Linode [note: affiliate link]. A DSN should run on virtually any shared hosting environment and be easy to install and configure, even for people relatively new to unix / linux.

Data, storage & upgrades

When Facebook or LinkedIn roll out a new version, they can do so simultaneously for everyone. A DSN will not have this luxury, and will need to provide interpolation between systems running different versions. And when security holes are discovered, it will at times be necessary to perform swift upgrades, or block access to other systems running outdated software.

In my experience, one of the more painful parts of performing upgrades is upgrading the database. This usually involves a massive transactional script that creates and alters columns and tables, and shuffling data around to fit in to the new format. Another method is by exporting all the data, altering the database schema, and re-importing. In either case, you would need to support upgrades between any two versions of your database, which will swiftly become a maintainance nightmare.

Updating code is simple. You can just checkout the latest version, and point your webserver at the new diectory. The bottleneck for upgrades is the database, so a successful DSN will probably use some kind of schemaless datastore that changes as little as possible between different versions.

Security and reputation

When Diaspora released their eagerly-awaited source code people were quick to point out on the lack of security. Patrick McKenzie of Bingo Card Creator remarked:

The bottom line is currently there is nothing that you cannot do to someone’s Diaspora account, absolutely nothing.

I feel sorry for the Diaspora guys in this respect, because after the overwhelming response to their Kickstarter funding drive (even Mark Zuckerberk donated to the project) the pressure was on them to produce some usable software. Which they did very successfully, unfortunately some security considerations had to take a back seat to achieve this. And despite pointing out that it was a developer release, and they were aware of security holes and bugs, the project received heavy criticism.

A general consensus arose that data security is not something that can be tacked on to a system, but needs to be built in from the start. While this sentiment has merit, I'm not sure it's entirely true. It's certainly much harder to add security later, but not impossible. With a bit of elbow grease, a lot of refactoring and a battery of tests, anything can be achieved.

So for the sake of ease of development and project reputation, a DSN should build in security from the beginning and pay close attention to security and privacy issues. Also:

  • Have a special 'VIP' route for collecting security related bugs, and make it easy to do. Think: security@my-dsn-project.org
  • Respond swiftly to these issues. Get on top of the issue before The Register does.
  • Get people with security experience to work on the project
  • Develop a battery of security-related automated tests
  • Be open and transparent about security issues which affect the DSN
  • Clearly distinguish between versions considered secure and non-secure

TL;DR

I had planned to end this post by talking about the features it would be cool to have in a DSN, and also about more nuts-and-bolts issues, but I think I'll save them for another day. Here's a quick summary:

  1. Don't just mimic the features of Facebook, Myspace or LinkedIn. Do something new and compelling
  2. provide simple, reliable control over personal data
  3. Make it as easy as Wordpress to install, setup and hack
  4. Provide interpolation between versions
  5. Make it easy to upgrade
  6. Build security in from the beginning. Make it easy to report security issues and handle them swiftly.

blog comments powered by Disqus