Which is better: A centralized social network like Twitter, or a federated one like ActivityPub as implemented in Mastodon or Pleroma?
Does federation solve all the problems of centralized services?
Issues with Centralized Services
Twitter is a centralized internet service. A single company runs it; that corporate hierarchy rules it. Lots of the popular services that people use to communicate and cooperate work this way: Facebook, Amazon, Discord, Reddit, all of Google’s services including Gmail and YouTube, etc.
This style of centralized service is great for the company running it. They own the site, so they can make whatever decisions they want without needing to even seek user input. And once one service gets ahead in users, they’re really hard to compete with due to the network effect and various intentional lock-in techniques.
The network effect is pretty powerful. The idea is that for some services, most of the value is in the other users using the service. You can’t just compete with Twitter. Even if you launch a competing service that’s objectively better in every technical metric, nobody will use it because all the users are on Twitter. Maybe if you pick the exact time when Twitter is down for a month you can replace them, but you can never compete with them.
Centralized services have some pretty big issues:
First, there is no privacy. The admins have access to all the data entered into the service by anyone. In some cases they’ll claim encryption or something; but go watch my videos on the Snowden leaks and the Lavabit shutdown.
Second, they have control and eventually they will use it. Google search results are tuned for the benefit of Google. Facebook filters what posts you see to benefit Facebook; really, the PR department helps tune the filters. Amazon promotes their products above those of external sellers. Credit card companies keep banning porn payments.
Twitter once banned the sitting President of the United States; now, that guy was an asshole, but a private business having that level of administrative discretion to muzzle government officials is kind of crazy. The problem isn’t so much the ban; the problem is that Twitter is so dominant that this mattered at all.
Third, centralized services are a fragile thing to depend on. If your business relies on Amazon and either Amazon goes down or they ban you, then you’re probably out of business.
If large centralized services have issues, what are the alternatives?
One thing we used to have is smaller, topic-specific centralized sites. Unfortunately, the network effect makes it hard for them to survive. A lot of things that used to be a web forum have turned into a Facebook group or a Discord.
One idea that helps turn the network effect in favor of smaller services is federation. The idea is that a bunch of different people and organizations can provide a service, and all of those services will inter-operate. The traditional example is email: everyone can host their own email server for their own domain, and email from one server is passed along transparently to whatever other server the recipient uses. Alternatives to email need to compete with the network effect of every email server, not just one.
There’s been a push recently to build federated systems for social networking. The ActivityPub protocal allows functionality like Twitter or Instagram in the form of programs like Mastodon, Pleroma, or Pixelfed.
So instead of being @BobThePlumber35 on Twitter, you end up as @email@example.com. And instead of following the Twitter terms of service, you need to follow the rules for “whiskey.club”. And you can mostly talk to anyone using ActivityPub, except that the whiskey.club admins have blocked federation with cheapbeer.rules because those plebs have no taste.
So is joining a Mastodon server really better than Twitter? Maybe. Unfortunately, federation as a solution for social networking has a serious problem: there are still admins. Those admins are either random people or people you know, and neither of those is great.
Would you rather be on the microblogging service run by Jack Dorsey or one run by your mother in law? How about one run by your local political party? Your employer? Your union? A random dude from New York who’s really into baseball?
Unfortunately, the large faceless corporation might actually be a better choice than the smaller service. You’re not going to get into a personal feud with a Twitter admin, and even if you do they’re unlikely to abuse their position to mess with you. Even if you get divorced or change political affiliations or employer your @Sally1987 Twitter handle is still valid. Your @firstname.lastname@example.org Mastodon handle might not be the public identity you want to use forever.
Even if you do find a federated server that works for you, that only reduces the issues with a centralized service. The server still has admins, so you still need to worry about privacy, control, and reliability.
Fully Decentralized Systems
What if we get rid of admins entirely? Is it possible to build a fully decentralized internet service?
It’s possible, but difficult in general. Centralized and federated services avoid a bunch of problems that can’t be avoided in a decentralized system - for example, in a decentralized system it’s impossible to guarantee unique names.
The good news is that there is a reasonably well established fully decentralized social networking system. It’s called Secure Scuttlebutt. It’s not perfect, but it demonstrates solutions to some of the major issues with more centralized solutions.
SSB was developed by a guy who liked to spend a bunch of time offline. Really offline, out in the ocean on a sailboat. So it’s designed to work without any internet connectivity. Users make posts locally on their personal devices, and posts are primarily synced directly to other devices when people meet up in person. This includes distributing posts for friends and friends-of-friends, so you’ll get to see posts from friends you haven’t seen recently in person as they propagate through meetings in the natural social network.
SSB also has mechanisms for syncing over the internet, both direct peer-to-peer connections coordinated by a DHT and through servers called “pubs”. A pub is just an instance of the software that’s always connected to the internet with an identity that doesn’t represent a real human. If you’re friends with pub, it can both sync posts to and from other friends connected to that pub and you’ll sync posts from other users of the pub (since they’re friends of a “friend”), which gives a mechanism to discover new people.
One of the things that’s nice about SSB is the story on moderation and harassment. There’s no searchable global public identity, and you only see messages from your friends and their friends. Further pubs are generally small and can only be accessed by invitation, so SSB doesn’t tend towards the social atmosphere of the normal public internet. If there are obnoxious people who you see posts from, you can simply block them. If a friend or pub keeps following obnoxious people, you can stop following them.
The protocol does have two critical problems. First, it explicitly doesn’t support using a single identity across multiple devices. Second, all posts are public and signed; it would be nice to be able to post to specific groups of friends and then to have those posts be denyable. There is support for private messages, but that’s not quite the same thing and those are also signed.
That being said, both of those issues are easily solved with backwards-incompatible changes.
Testing Secure Scuttlebutt
I’d like to spend some more time testing SSB, especially to try to get a better understanding of how the identity model ends up working, especially with people who I can’t meet in person to set up a follow locally.
I’ve set up an SSB pub server. If you’d like to join me:
- Use the invite below invite to join my pub. Note that this invite works a limited number of times; if that runs out, I may post a new one here.
- Make a post mentioning me using the user account and fingerprint below.
invite code: mist.fogcloud.org:8008:@k6249Ui6kVhuIYRrx+9dnDVaNm+4NzXzd9vH0lzPH1k=.ed25519~HeZn7/3dtq5DCX0XJE4Dzc6Ae7V6b2efkoyDE94UZ5M= mention with: [@Catostylus](@GqOpOJGLILNdEsvQC/w2L0DQXVrvYwMWcL2GuGz5X0M=.ed25519)