Federated, Decentralized, and E2EE Networks: Similarities, Differences, and Trade-offs
(TL;DW)
If you think about the history of computing, there’s a general trend that appears:
When a new advancement is made, it tends to be very large, very expensive, and usually only available to those who can afford the extravagance (or have / convince themselves they have great need). But as long as you have the money, space, or whatever resource is required, there’s no real barrier to getting one–there’s so few instances of the new tech out there, you can’t really even hope to connect it to get any sort of network benefit.
As time goes on and the new technology becomes more affordable, it typically enters the realm of “too expensive for the home, but businesses might have one.” In this phase, there’s a powerful incentive for businesses to create network effects, often by advancing their own patented or unique revision of the technology, in an effort to first convince people to use it, then make it difficult or costly for them to leave it, then use that increasingly captive audience to convince others to join their particular walled garden.
But as the technology continues to advance and becomes faster, smaller, cheaper… there’s more capability for people to begin making use of it at home. And naturally, they want to use it in the way that suits them–which is not always the way the businesses who created the walled gardens want them to use it. Over time, the growing ubiquity of the new technology can result in people overcoming network effects just because of the sheer number of people working against those effects in all their myriad ways.
Now, let’s think about social computing in this fashion. The earliest stages of social computing were very much about protocols, but they were somewhat unwieldy to employ and required a lot of resources to use, tied as they were to large computing systems and communication infrastructure that was rather resource-intensive.
As time passed, these large systems became easier to set up and use, but… communications infrastructure was still lacking, and running large websites at home was frequently infeasible. This led to a centralization effect, where a site managed by a business could benefit from having those network effects–more users could mean more revenue, which allowed them to expand the site. It had the potential to be a positive feedback loop, if the effects of greed and profit-seeking were kept at bay.
But over time, the technology available to us has continued to increase. We have more powerful computers, and always-on broadband connections are much more commonplace. We could very well be approaching the time where people can pull their “social networks” (in the sense of a service or a site) back out to the edges of the network, rather than keeping them held in a centralized location.
And this leads us to decentralized networks!
There’s certainly more than one style of decentralized network, taken as an umbrella category. If you want to replicate the look and feel of something such as Twitter, perhaps you might start by creating your own Twitter-like website that you can run on your own equipment. And hey, maybe somebody else runs their own copy of the software, too. A protocol can connect the two of them so you can see each other’s activity–this is a federated system.
I would categorize a federated system as a midpoint along the continuum of decentralization. It’s still a somewhat-centralized service, after all. The admin may federate with other servers… or they might not. You still have to find and choose what server you want to sign up under, and if you go create a new account on another server, well… that’s a different account on a different server, and you might need to rebuild your post history and your social graph from there.
There are other styles of decentralized network–P2P and blockchain are two other mentioned by Jeong et al. (2025). But if you continue pulling the social network out to the edge, the logical endpoint is a system where everybody has their own “site.”
The example I would use of something like this would be Bluesky and the AT Protocol, which you may have read about in Unit 8! Under the AT Protocol, every user has a globally unique decentralized identifier. The human-readable handle can be changed, but the DID remains unique, no matter where you go. And you can go wherever you want–the DID can be updated to point to a personal data store, or PDS, that can be placed wherever you choose. It can be on Bluesky’s servers, or you can run it yourself. That PDS contains your posts, your social graph, and all the data that is “yours.” If you want to go somewhere else, you simply move your PDS to a new location, with no need to rebuild from scratch.
By contrast, end-to-end-encrypted (E2EE) networks are a different breed entirely. They certainly can be decentralized… but that introduces new challenges.
In an E2EE network, everything is encrypted at the endpoints before being transmitted. No middle points along the path can read the traffic. That’s already a benefit. Of course, metadata and traffic flow analysis can be used to infer other data about the communications, and so E2EE is often also implemented in a completely decentralized fashion.
But one of the biggest challenges of E2EE is key management. That is, if the encryption keys are only managed at the endpoints… how do new endpoints exchange those keys? If I only accept encrypted traffic, how do you send me a message to ask for my encryption keys? I would have to post my keys somewhere, and before you could try to talk to me, you would have to find wherever I put my keys.
In the realm of OpenPGP, keyservers are a common answer to this quandry. But a keyserver is a point of centralization–the bigger a keyserver becomes, the more useful it is for people to use it, and the more the network will de facto depend on it. So already, we see where centralization still plays a very important role in making E2EE networks convenient for users.
Signal is an example of an E2EE network, but still maintains a centralized service to facilitate key exchange and introduction. But because keys are essentially tied to the endpoint devices, the loss or rotation of a device can mean the entire messaging history is lost. This would not be acceptable in a social network. More recently, a newer E2EE protocol (based on the Signal protocol) has been developed to try to extend the benefits of E2EE to social networking applications as well.
Decentralized and E2EE social computing is an area of social computing that has held my fascination for a long time, and probably will in future as well! Hopefully this was an interesting overview of this area for you, too!
References:
Basem, O., Ullah, A., & Hassen, H. R. (2023). Stick: An end-to-end encryption protocol tailored for social network platforms. IEEE Transactions on Dependable and Secure Computing, 20(2), 1258-1269. https://doi.org/10.1109/TDSC.2022.3152256
Jeong, U., Ng, L. H. X., Carley, K. M., Liu, H. (2025, March 31). Navigating decentralized online social networks: An overview of technical and societal challenges in architectural choices. arXiv preprint. https://doi.org/10.48550/arXiv.2504.00071
Masnick, M. (2019, August 21). Protocols, not platforms: A technological approach to free speech, 19-05. Knight First Amendment Institute. https://perma.cc/MBR2-BDNE
Leave a Reply