Federation is still the Worst of All Worlds
In short: The threat model and economics of federated systems devolve to concentrating trust in the hands of a few, while missing out on the scale advantages of purely centralized solutions.
derived from my older post: https://fieldnotes.resistant.tech/federation-is-the-worst-of-all-worlds/
Federation results in the data of people being subject to the whims of the owner of the federated instance. Administrators can see correspondence and derive social graphs trivially. They are also in a position to selectively censor inter-instance communication. All of this while gaining none of the benefits of scale and discovery that centralized systems provide.
All the privacy and control issues, none of the scale advantages.
Are those problems inherent to federated systems? I would argue yes, at least in the context of how we think about federation today.
To achieve some level of usability, to present the user with a known interface, we require trust in the federated server.
Without building consent and resistance into the protocol and infrastructure, we’re just forcing most users to pick a new dictator for their data without any real basis for that choice.
This last bit is very important.
I need to emphasize here that the choice is that arbitrary - you may trust a community server more than a random billionaire or corporate board, you may even desire it - but all power, especially the most trivial power, corrupts.
If people can do harm with a system they will do harm with a system.
The goal of system designers should be to design systems that minimize harm, restrict power, and reduce trust.
We must develop better models than “the most popular federated instances gain full control over the users interactions” - either directly on the server, or indirectly through peer pressure.
I believe this requires building two layers of decentralized communal infrastructure:
- A privacy preserving persistence layer removed from any specific application.
- An application layer which can interact with it, and provide features for it (microblogging, social networking, filesharing, collaborative editing etc.)
(first person to say blockchain loses.)
You need that first persistence layer to be communal and privacy preserving to prevent any entity being in a position do something like “all the DMs on this instance are readable by whoever admins it”.
There are a number of open problems with approaches like this, the main two being Reliability & Discoverability. However, I don’t think that either problem is fundamentally intractable.
I’ve been saying this for a long time though…
Even if the ultimate solutions to these problems involve introducing a layer of federated trust (e.g. nameservers), that trust must be more restricted, agile and controllable than is currently achieved with modern federated systems.
I wrote the original version of this note 5 years ago, since then a few projects have put out preliminary visions and designs towards a better decentralized social network (e.g. bluesky and manyverse).
I hope that these initiatives can blend together and with the work done on privacy in recent years by briar and my own cwtch and the many other decentralized projects that have developed in recent years to make progress on the very real and difficult problems in this space.
All have different strengths and weaknesses, different goals and aspirations - but we all fundamentally want the same thing - a free and open internet that supports people in finding community and a voice.