I can’t remember when I started hearing about the FreedomBox, though it feels the idea has been circulating since much longer than the project announcement in early 2010. Either way,...

I can’t remember when I started hearing about the FreedomBox, though it feels the idea has been circulating since much longer than the project announcement in early 2010. Either way, it is a project aiming at disrupting the centralisation of cloud [dis]services that are so popular right now.

The FreedomBox is a tiny router-like computer which intends to provide easy-to-use, privacy-minded web browsing, sharing of files and secure e-mails. A prominent feature in the list is enabling anonymous internet usage through services like Tor. All these are good projects with lots of code that just have to be put together. That is unfortunately not the case for the bullet point “Safe social networking”.

The untrusted third party

Social networking today is centralised. The workflow is generally dependent on a website you (or a designated “app”) visits where it is possible to exchange messages with other people also registered on that same site. If you wish to communicate with a friend not using the specific service, either one of you must register a new account with the other person’s service. One’s only relation with the new service is the person one wishes to communicate with – still users supply personal information such as e-mail address, name and often a commonly used password.

There is no reason to believe this new service would treat you or your personal information with respect. Think of it, this service gladly acquires your security credentials (storing them where and how?!), use your account data in business deals with third-party companies you’ve never even heard of, continuously send you messages unless you have unchecked all the appropriate boxes in their proprietary, non-standardised settings configuration. And. Lots. More.

The FreedomBox’s role in this situation is to provide you as an individual a social environment. An environment that the user controls, rather than the provider. Think of it as a party at your home – where you control the guest list – or going out to a night club where beefy guards pick and choose arbitrarily who gets in and who is thrown out. In a safe social environment there should be no need to supply a strange company private details just because they control your friends’ communication habits.

A federated social web box

As mentioned however, not all the necessary code is written for this step. The FreedomBox is not yet quite ready to take the step into a decentralised social environment on its own. There’s some key functionality that is missing, incomplete or simply not working today. To understand what the issues are, some main differences with a centralised and a federated social network are listed here:

• Discovery.
  • With a centralised service discovering new connections and initiating communications is a no-brainer. Just search your own database and if you can’t find something, it’s simply not there. When trying to find a certain person (by e-mail or otherwise) one will often be encouraged to invite them.
  • Federated networks will often find that the user is not local. Information, messages and metadata are located on other servers and today there are countless algorithms (and formats) when looking for contacts. Unfortunately very few federated services today can exchange information flawlessly.
• Distribution.
  • Again, a centralised service knows exactly which harddrive and memory segment contains certain data – and adding stuff to an inbox or activity stream is nothing more than saving that data to a file in the right place. If it doesn’t work, the entire service doesn’t work – and you might get a fail whale.
  • Federated distribution is hard. Realtime distribution is not a problem, but where do you send the info? And should any further metadata be broadcasted to (see “Discovery” above)? How do I distribute an updated [text|document|media] properly? What happens if the remote server is currently offline?
• Privacy.
  • This is where centralised services have it the easiest but are the worst. Not only is information distributed to unknown third party consumers but database leaks, software bugs and such will cause problems for many more users in a centralised environment than on a single-user platform with limited data.
  • Federated services are good at privacy. If you don’t want to leak information, just don’t federate. Or don’t federate to untrusted entities. Create a pseudonym (or five). Lots of functionality here exists in software and protocols. The only unsolved issue to date is federation of private texts. GPG can do this though.
• Statefulness.
  • In a centralised environment there is only one state. A user, post or relation exists or it doesn’t. This extends to user identities: “There can be only one!”. This enables certain control for trademarks, and definitely simplifies work for the software developer.
  • Federated states are fragmented. Heavily so. The positive side is that anyone can get their own username, like with e-mails. If you’re disappointed that your.name@example.com was taken, choose your.name@example.net instead – or any other fully qualifiable e-mail address. The downside is that network lag or temporary downtime can cause replies to be delivered before the original post and other curious dilemmas.

I believe the most interesting dilemma is the statefulness. That discussion includes all the difficulties of distributing stuff, deleting stuff and of course how to handle situations where perhaps different policies are applied to things like friendships/subscriptions. Perhaps one server won’t allow non-”friended” users to deliver messages, whilst an entire discussion thread arises on all other servers where this message was delivered. If the discussion includes some of the “friended” users – how should those messages be handled if part of an “non-friend” discussion? Is it even possible to standardise these behaviours in a manner that will satisfy all users?

Nevertheless, I believe the FreedomBox will play a big role in adapting federated social web services to a more stateless community. Discovery and distribution must assume not every entity is available 100% of the time. Privacy issues must be handled with standardised (reliable) protocols and algorithms. The data storage must then also allow for retrieving data via a distributed data model where the current full state is not necessarily stored on a single place.