Driven by commercial motives, corporate-controlled social media platforms emerged and greatly undermined people’s initial hopes for online participatory culture. Online information technology should have fundamentally democratized cultural production, but today, these profit-driven platforms restrict and shape online behavior—“likes” are not a thank you for the content, but a commercial tool.

Alternative social media platforms built on decentralized technology and federated protocols recreate the original vision of online social interaction. Data is controlled by users and recorded in decentralized databases, the front end is driven by the community, the audit is an expression of community preferences, and the algorithm is selected by users. This is an open source spirit that drives innovation.

The History of Decentralized and Alternative Social Media

Before the web became a hub for commerce, entertainment, and social interaction, it was primarily an academic and military tool. Tim Berners-Lee had an egalitarian vision when he developed the first web protocol: the original design of the internet was a decentralized network where information could flow freely between nodes, with no individual in control and no single point of failure.

However, as the commercialization of the web grew, centralized platforms such as search engines and social media giants became dominant. While these entities provided tremendous value, they strayed from the original spirit of decentralization, leading to our current Web2 environment.

A key innovation in the development of alternative social networks is the emergence of the concept of federated protocols. A federated network is a system of independent servers or “nodes” that work together to form a social network, as opposed to centralized platforms where one organization controls all the servers.

In a federated network system, each server runs software that follows a shared protocol, which enables them to communicate with each other. Users registered on one server can seamlessly follow users on other servers, interact with users on other servers, and share content, just as if they were on the same platform. Examples of federated protocols include ActivityPub and OStatus, which power federated platforms such as Mastodon and PeerTube.

In a federated system setting, users can choose which servers they trust, they may migrate to different servers or set up their own servers, and they are given more autonomy. The term "Fediverse" (a portmanteau of "federation" and "universe") is used to describe such a system. The Fediverse began with the GNU Social platform and its predecessors (Statusnet and Laconica), but the real turning point was the development and widespread adoption of the ActivityPub protocol, which was published as a recommendation by the World Wide Web Consortium (W 3 C) in 2018.

In Web3, federated social networks are the default state of decentralized systems once data is ported on-chain. The blockchain acts as a backend server that stores content, and the frontend indexes this content and serves it directly to users. Identity is tied to a public-private key pair that manages the user's wallet, and users are able to easily verify any data or content they generate. Additionally, using on-chain primitives such as NFTs, stored content can be bundled in metadata and act as a domain name or decentralized identity (DID).

Similar to how ActivityPub works, Web3 protocols seek to bootstrap the social graph through authenticated relationships between user nodes. Since any frontend can index and serve this content, there is intense competition at the frontend layer and new features thrive. Additionally, since the data is stored on-chain, users can choose the algorithms they prefer and they can be incentivized to recapture the value of their data using certain algorithms. This, combined with a more direct means of monetizing content, provides a better overall experience for creators who have been largely excluded from monetization, despite their content driving demand for these platforms.

Protocol Comparison

To truly understand the innovations in decentralized social media protocols, it is necessary to understand the technology that implements them. It is worth noting that we have not included all social protocols here, but rather selected some of the most popular ones:

Identity / Namespace

In federated and decentralized social graphs or network protocols, a "namespace" refers to a domain where user identifiers or other resources are unique. It is a way to distinguish resources or identities from one domain/server from another, ensuring that there are no conflicts and ambiguities when integrating or communicating across multiple domains.

Identities and associated namespaces for different decentralized social protocols range from simple key pairs ( Nostr , Scuttlebutt ), to URIs pointing to hosted profiles ( ActivityPub ), to more complex models using on-chain primitives like NFTs (and recent ERC-6551 extensions like Lens V2 ).

Farcaster is a great example of these technologies. A Farcaster account represents a unique entity on the network. Each account has a unique numeric identifier called a Farcaster ID (fid). Identities are managed on-chain using an Ethereum contract called the IdRegistry, and users make transactions to the IdRegistry to get new fids. The address that owns the fid is the user's managed address. The IdRegistry ensures that the fid can be transferred between addresses and that no two addresses have the same fid. Farcaster also extends this namespace to support ENS domains issued on or off-chain. Users must submit a signed proof to the network to claim a username.

ActivityPub, on the other hand, identifies each user through a unique URI (usually an HTTPS URL). This URI points to the user's profile and serves as their global identifier in the Fediverse. To make these URIs more user-friendly, many ActivityPub platforms use a system called Webfinger. Webfinger allows users to have an identity similar to "@username@domain.com".

Lens and CyberConnect manage user profiles as NFTs. Taking Lens as an example, one user address holds one Profile NFT, and a single address can hold multiple Profile NFTs. Each Profile NFT encapsulates the entire history of a user's activity. In addition, Profile NFT has a FollowModule, which is essentially a set of rules that govern how different accounts obtain Follow NFTs. These Follow NFTs record the connection between an account and a profile directly on the chain. There are also handles that can be created separately from profiles and can be linked or unlinked from one profile to another. Handles exist in their own namespace (e.g. lens/@alice).

data

Data is arguably the most important feature of decentralized networks, as the creation and standardization of data is fundamental to these systems. The most common technique for managing data here is to use standardized formats such as JSON and common relationship objects (e.g. likes, following). Core data objects typically include:

  • Subject & Object: Defines "subjects" (e.g., users) and "objects" (e.g., posts or messages).

  • Publications: Posts or comments are packaged as "publications", which usually link to external content via URLs.

  • Append-only logs: Each entry (whether a post or an update) is a log of discrete content items, added and stored sequentially.

Let's dive into a few examples to see how specific protocols work.

ActivityPub leverages the ActivityStreams 2.0 data format, a JSON-based data structure, to represent social interactions such as posts or likes. The protocol consists of two main components: Client-to-Server (C 2 S) and Server-to-Server (S 2 S). C 2 S allows users to interact with their respective servers through client applications. In contrast, S 2 S facilitates communication between servers, enabling the robust federated nature of the protocol.

In ActivityPub, entities are classified into "subjects" (usually user accounts or groups) and "objects" (content or operations, such as posts or likes). When a subject performs an action on an object, it creates an "activity" object, such as "create", "follow", or "like".

The Web3 social graph borrows many core ideas from ActivityPub, but applies them to the blockchain. For example, Lens Protocol introduces "publications", which encapsulate various user-generated content such as posts, mirrors, comments, and other forms of media. Each publication is associated with a ContentURI that points to specific content stored on decentralized protocols such as IPFS or Arweave or centralized storage services such as AWS S 3. This design ensures that users' profiles and all related publications are securely stored in their personal wallets, thus getting rid of dependence on centralized databases.

Furthermore, Web3 provides a more direct way to monetize user content and influence than the Web2 architecture. Users can charge for the minting of Follow NFTs, or integrate Collect Modules with their publications. The latter option allows them to charge for the minting of NFTs linked to the ContentURI of their publications. In addition to these features, Lens Protocol also provides a GraphQL API for shielding blockchain components from the front-end interface, providing a more user-friendly experience than previous decentralized social networks.

Finally, many decentralized social networking protocols create append-only data structures, authenticated by user keys. For example, on CyberConnect, each piece of user-centric data is represented as a data stream, where only the data owner is allowed to update. Each update to the data is appended to the data stream in the form of an append-only commit log, and the resulting data structure becomes a hash-linked data structure called a Merkle DAG. Data types include content, favorites, comments, and subscriptions.

Scuttlebutt also uses an append-only log data structure. Each user has their own log, where each new message or action is appended to the end after being signed by the user's identity. It also supports sharing of binary data called "blobs". These data can be images, videos, or any other binary content. Blobs are stored separately from the append-only log, but references (hashes) to these blobs can be included in the log.

For Farcaster, messages are public updates, such as posting, following, or adding a profile picture, which are encoded as protobuf and must be hashed and signed by the account signer. Users can publish messages to the Hub as long as there is enough storage space. The HUb checks the validity of its signers before accepting each message.

storage

Data storage for early decentralized protocols was primarily off-chain. For example, Scuttlebutt uses a peer-to-peer gossip network to store data on the user's local device. This approach ensures data sovereignty, as users have full control over their information. However, it also means that data availability depends on whether the user's device is online or other nodes in the network have a copy of the data. Over time, in order to manage storage space, some Scuttlebutt clients may need to implement garbage collection strategies to delete old or less relevant data.

An alternative to this peer-to-peer approach is the emergence of data storage servers. In Matrix, for example, multiple homeservers store copies of the room history and synchronize with each other. When a user sends a message (or any event) in a room, their homeserver broadcasts the event to the other homeservers, which then store the event and forward it to their connected clients. Similarly, ActivityPub lets each instance (or server) in the network store its data, typically in a database. The choice of database (relational, NoSQL, etc.) depends on the specific implementation of the ActivityPub software. For example, the popular ActivityPub platform Mastodon uses a PostgreSQL database.

Protocols such as Cyberconnect, Farcaster, and Lens have adopted blockchain for storage. On-chain storage ensures the immutability and verifiability of data, providing a solid foundation for decentralized applications that synchronize state using the underlying consensus mechanism. However, this approach may pose scalability challenges, as every piece of data needs to be stored on-chain, which may result in high transaction fees and slow retrieval times.

This has led many Web3 social protocols to try a hybrid approach, using on-chain storage for low-frequency operations (e.g. profiles, subscriptions), off-chain storage for high-frequency events (e.g. likes, retweets, comments), or using off-chain storage as a temporary stopgap to batch upload data to the chain at certain time intervals.

CyberConnect uses hash linked lists in decentralized data storage to efficiently handle frequent updates between user connections. When a connection is initiated, an "operation log" is created. Subsequent state changes (such as switching between following and unfollowing) are added to this log as new nodes. Although these updates are initially stored on centralized servers, they are periodically uploaded in batches to decentralized storage platforms such as Arweave or IPFS. In order to enable fast retrieval of data, the nodes in the operation log are stored centrally. However, users can independently verify data integrity by browsing this hash linked list. Even though some data queries rely on centralized servers, CyberConnect's system is designed to be fully decentralized while also providing high performance.

Farcaster uses a similar hybrid approach: on-chain contracts are used for low-frequency operations that are important for consistency and decentralization. Accounts, usernames, storage, and keys are managed using a series of Ethereum contracts. Off-chain systems are used for high-frequency operations that depend on performance. User account creation messages are stored and propagated on the Farcaster hub's peer-to-peer network.

discuss

Decentralized social protocols are poised to revolutionize user experience in digital interactions. The accelerated adoption of public-private key pairs driven by Web3 will help to more broadly understand identity primitives in this context, and continued auditing and data capture by Web2 social media companies will drive more users elsewhere. We expect the adoption curve for these decentralized social protocols to accelerate.

In order to promote the development of innovative applications, protocol developers and open source contributors urgently need to go beyond the basic data types and relational objects currently used in the infrastructure layer. Although the existing primitives fully encompass the functions of traditional Web2 social media, there is still huge potential for expansion and innovation. Most of the protocols discussed here inherently support extensibility within the system, providing a solid foundation for future development and open source contributions.

However, interoperability is also critical. While front-end developers are able to enhance functionality independently, doing so could harm the overall benefits of the system if the enhanced functionality is not interoperable with other applications built on the same underlying protocol. Ensuring compatibility and seamless integration between various applications is critical to the long-term success and adoption of decentralized social protocols.

In the area of ​​data storage, Web3 social protocols tend to adopt a hybrid approach. Allocating high-value assets such as identity and primary content to on-chain primitives, while allocating low-risk content such as likes to off-chain solutions. This balanced approach not only preserves the integrity and security of critical data, but also provides a user experience close to traditional social media platforms.

Decentralized networks promise to transform interpersonal communication, information sharing, and community building. By prioritizing user autonomy, privacy, and fostering organic relationships, these networks are paving the way for a more equitable and user-centric digital environment. Additionally, the decentralized nature of these networks helps democratize access to information and resources, mitigating the risks associated with centralized control.