We’re going to explore different decentralised social networks and assess their degree of decentralisation by examining architectural, logical, and political aspects. We’ll consider both the macroscopic perspective (the network as a whole) and the microscopic perspective (the individual user’s experience).
Each network employs unique strategies to decentralize different aspects of its operations, impacting how control is distributed across the network.
Let’s start with ActivityPub, most famously used by the Mastodon and Threads networks.
ActivityPub follows a classic federated model, similar to email systems. Users belong to home servers that communicate with each other to pass messages. Users don’t control their identities; server administrators do. There’s minimal cryptography involved—messages are often encrypted in transit using Diffie-Hellman key exchange, but users have no personal keys. It’s a custodial network.
Architecturally, Mastodon is decentralised on a macroscopic level because any server can go down without disrupting the entire network. However, from a user’s perspective, if their home server goes down, they lose access and data. Logically, the network is centralised on a global scale since there’s a potential global feed of all messages between servers. Microscopically, it’s decentralised because home servers can limit views based on policies.
Politically, ActivityPub has centralisation points. The W3C standards body controls protocol decisions, often influenced by big tech companies. Server administrators can block messages or entire servers for anti-spam or political reasons, which is a positive design choice. However, in practice, these blocks often come from aggregated blcklists which are influenced by administrator political opinions rather than just spam concerns, and what emerges is a system of global banning based on the views of the administration class…
Users have no recourse if banned or if their messages are blocked; they must start fresh on a new server.
Farcaster uses an on-chain user registry and a peer-to-peer network for messaging, with intermediary servers helping bridge connections due to NAT issues in IP addresses and routers. Architecturally, this setup offers redundancy since the user registry is always accessible via the blockchain, and the network is accessible via p2p routing.
Logically, Farcaster is centralised as there’s one set of messages for the entire network. Users also experience this logical centralisation since they access the global state of messages.
Politically, Farcaster is highly centralised due to its governance structure. The user registry is controlled by smart contracts managed by a small team within a company. That company is backed by venture capitalists who push for value capture through centralisation. The most-used client, Warpcast, is closed source and owned by that same company, and due to it’s massive adoption (~50%) can impose protocol changes that others must follow. This pattern repeats from browsers and operating systems; even though standards may exist, the dominant players dictate their true adoption.
This pattern mirrors Jack Dorsey’s argument about Twitter’s decentralisation: if those controlling the code and network are driven by investors seeking high returns, they’ll lean towards centralisation to capture value and support commercial models that benefit investors.
While the on-chain registry is immutable, control over the primary client software allows for user bans at the application level. The primary client being closed source and controlled by a single company introduces the potential for future changes that could centralize control or introduce censorship.
Bluesky operates using the AT protocol, originally developed for Twitter to facilitate decentralization before being abandoned by Twitter after its acquisition by Elon Musk.
Jack Dorsey, then CEO observed the increasing challenges Twitter faced with censorship demands from countries and advertisers. Jack believed that no single entity, including Twitter, should wield such control over our communication. The aim was to create a decentralized protocol that would alleviate many of Twitter’s liabilities and improve internet communication.
Technically, they made some forward-thinking decisions. Users could assign themselves a Decentralized Identifier (DID) using the W3C standards. This required a registry to map DIDs to Public Key Infrastructure (PKI) key pairs, giving users control over their identity through their private keys. However, for ease, they initially chose a centralized registry controlled by BlueSky, which could arbitrarily remove accounts. Users could alternatively use their own domain names as registries, but this was rare, and even then introduced political centralization via since ICANN and national governments can, and have, taken domain names away from their users. In this case, this would strip them of access to their identity.
The network consists of three types of servers: personal data servers (PDS), relay servers, and labeling servers. PDS administrators don’t control user identities; they simply host data, allowing users to switch servers while retaining their identity. (This akin to ActivityPub’s concept of a home server, however, account registrations are not stored on their PDS. This enhances account portability and resistance to censorship by individual server admins, yet increasing the risk of censorship by the centralised registry .)
Messages from PDSs are sent to Relay servers, which run user-selected algorithms to generate feeds based on labels. Anyone can operate a Labeling service or algorithm on a Relay, which decentralizes the logical aspect of feed generation and input processing.
Relay and labeling servers enable users to choose different algorithms for their feed, fostering an open marketplace and user agency.
Architecturally, the system is redundant except for the centralized registry. This poses issues both macroscopically and microscopically due to its lack of censorship resistance; BlueSky, a US company, can be compelled to remove users from the registry. Politically, BlueSky faces pressures similar to any private company with venture investments and board responsibilities. Logically, it’s centralised macroscopically because there is a global set of messages accessible from any login point, but from a user’s perspective it’s decentralised because each user’s view is a subset of the network based on their choice of Relay and feed algorithm.
Comparatively, ActivityPub allows users to jump between PDSs if rejected by an administrator. Despite BlueSky’s admitted registry issue, which could be solved using blockchain, those are not appealing to them due to their user base’s political stance.
Lens stands out because it is highly on-chain. User accounts and their messages are stored on the blockchain. One might assume this leads to significant decentralisation, but the reality is more nuanced. A key question we always ask is: where does centralisation occur?
Architecturally, Lens runs on a blockchain, providing high redundancy through blockchain nodes. This suggests decentralisation. However, a closer look reveals that much of the service operates like Web2 protocols for developer convenience, particularly through their GraphQL API (meaning their servers respond to the client’s data requests, instead of the blockchain). This introduces centralisation because communication between client and network happens via a centralised API, which can be a single point of failure for both the network and individual users.
Politically, as with any upgradeable smart contracts, Lens’s functionality is changeable by a small group of people, indicating political centralisation around Aave as a company, and the teams within it that control this code. Additionally, control over the API further consolidates power to the same group. Although user accounts are stored on-chain—suggesting they can’t be easily censored—the architecture’s reliance on APIs means these APIs could detect and filter out certain users. So users can, in practice, be banned or shadow-banned.
Placing all key data onchain ensures transparency but at the cost of user privacy. It also negatively affects user autonomy, as the smart contracts and intermediary APIs are controlled by Lens and Aave.
Logically, Lens is very centralised due to its single source of truth—the blockchain itself. As they move towards multi-chain systems with bridging, there might be delays, but eventually, network state consistency is achieved. From a user perspective, this means seeing consistent messages and usernames across the network.
The network’s operations are currently subsidized through gas-sponsored contracts, creating a centralization point around sponsors. This sponsorship mirrors the economic pressures similar to those faced by traditional social platforms like Twitter, which often led to calls for increased censorship and centralization.
So, while Lens appears decentralised, centralisation remain in its architectural design and political control mechanisms.
Nostr, inspired by the Bitcoin ecosystem’s principles but not blockchain-based, emphasizes a high degree of architectural decentralization.
Its architecture is simplified to avoid common problems seen in other projects.
In Nostr’s design, there is no centralized user registry.
Users generate public-private key pairs as their accounts without official registries; data transmission relies solely on event messages containing public keys for identification. Keys are distributed across events and stored on federated relay servers, and each relay is independently managed within its community.
Nostr further avoids centralization by not defining different actors with varying controls, which often leads to choke points inviting centralization. Instead, users belong to relay servers they can switch between if needed. Relays don’t communicate with each other; all communication happens at the client level without an official client dominating the network.
This model significantly reduces class distinctions between different network actors by eliminating server-to-server communication, a common cause of centralisation in networks like ActivityPub and Bluesky. However, this also introduces performance and speed challenges, especially when users subscribe to multiple relays.
Architecturally, Nostr is decentralized at a macroscopic level; the network persists despite relay fluctuations. Users face some inconvenience switching relays but maintain network access.
Logically, Nostr is unique among major decentralized networks: Nostr’s view of usernames and messages varies per user based on subscriptions without a central message superset reflecting the entire network state. This is known as a petname system, where usernames aren’t globally set, but set according to whoever’s talking to them. This might sound weird to you, but then it would also sound weird to you if I called your mother “mom”. “Mom” is your petname for her. If you think about it, humans naturally use logically-dentralised names for each other. We rarely refer to people by the full name on their government ID.
Politically decentralized too, Nostr’s protocol definitions are explicitely called “Possibilities” rather than mandates from a controlling body. These possibilities are posted on GitHub—a point of centralization—but compliance isn’t mandatory beyond the first document for clients or relays. We will see if, over time, this tiny crack of centralisation widens.
Centralisation and decentralisation both come from design decisions. Quite often those decisions are framed in terms of trade-offs, say between robustness and efficiency. But underlying them are incentives. There are usually economic gains available to those who try to “capture” network “value” through centralisation. Equally, there are societal and cultural benefits from investing in decentralisation.
For networks like Bluesky, adopting an immutable, on-chain user registry could decentralize control further, enhancing user trust and aligning with the principles of decentralized networks. Lens could benefit from diversifying control over smart contracts, perhaps by integrating decentralized governance to give users more autonomy over the network’s operations. It could also modify its library to use blockchain light nodes rather than web2 APIs. Nostr could improve performance and user experience by optimizing client capabilities to handle multiple relay connections more effectively. Farcaster could consider implementing decentralized governance structures to reduce the influence of central exchanges and investors on the protocol’s evolution, as well as open-sourcing its client and network stack.
By addressing these areas, each network can enhance its commitment to decentralization, providing a more resilient, user-controlled, and equitable digital interaction space.