Accelxr

Posted on Nov 30, 2023Read on Mirror.xyz

A Comparative Analysis of Decentralized Social Protocols

The emergence of corporate-controlled social media platforms, driven by commercial motives, has significantly eroded the initial hope for participatory culture online. Networked information technologies should fundamentally democratize cultural production, but nowadays, these platforms limit and mold online participation primarily for profit-driven purposes - a ‘like’ is not an expression of gratitude for a piece of content, but instead is a monetization tool that drives commercially-motivated algorithms.

Alternative social media platforms built on decentralized and federated protocols offer a return to the original conception of online sociality. Data is controlled by the user and is propagated across decentralized databases, frontends are community-driven, moderation is an expression of a community’s preferences, algorithms are chosen by the user, and an open source ethos drives innovation.

History of Decentralized and Alternative Social Media

Before the web became a hub for commerce, entertainment, and social interactions, it was primarily an academic and military tool. Tim Berners-Lee held an egalitarian vision when he formulated the first web protocols - the initial design of the internet was to be a decentralized network, where information could flow freely between nodes without any single point of control or failure.

However, as the web grew in commercial importance, centralized platforms, like search engines and social media giants, emerged as dominant players. While these entities provided significant value, they deviated from the original decentralized ethos, resulting in our current web2 environment.

The key innovation in the timeline for alternative social networks was the arrival of the concept of federated protocols. A federated network refers to a system where multiple independent servers or "nodes" cooperate to form a single social network, as opposed to centralized platforms where a single organization controls all the servers.

In a federated system, each server runs compatible software that follows shared protocols, enabling them to communicate with each other. A user registered on one server can follow, interact with, and share content with users from other servers seamlessly, as if they were on the same platform. Examples of these protocols include ActivityPub and OStatus, which power federated platforms like Mastodon and PeerTube.

In a federated setup, users can choose which server they trust, potentially migrating to different ones or setting up their own, giving them more autonomy. The term "Fediverse'' - a portmanteau of "federation" and "universe" - is used to describe such a system. The Fediverse started with platforms like GNU social 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 recommended standard by the World Wide Web Consortium (W3C) in 2018.

Within web3, federated social networks are the default state of decentralized systems once data is ported onchain. Blockchains act as an unopinionated backend server for stored content, with frontends indexing this content and serving it directly to users. Identity is handled by public-private keypairs that already manage user wallets, allowing them to easily authenticate any data or content they generate. Additionally, use of onchain primitives like NFTs can bundle stored content in the metadata and act as a domain name or decentralized identifier (DID).

Similar to how ActivityPub works, web3 protocols seek to bootstrap social graphs via authenticated relationships between user nodes. Since any frontend can index and serve this content, there is hyper competition at the frontend layer resulting in a flourishing landscape of features. Additionally, because data is onchain, users can elect the algorithms they are comfortable using, and they can be incentivized to use certain ones, recapturing the value of their data. This is combined with more direct means of monetizing their content, making a better overall experience for creators which have been largely left out of monetization even though their content is what drives demand for these platforms.

Protocol Comparison

To truly appreciate the innovations within decentralized social media protocols, it’s necessary to understand the technical nuances that enable them. Notably, we are not including all social protocols here, but instead opt for some of the most prevalent:

Identity / Namespaces

In the context of federated and decentralized social graphs or network protocols, a "namespace" refers to a domain or realm under which 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 aren't conflicts or ambiguities when integrating or communicating across multiple domains.

Identity and associated namespaces across decentralized social protocols run the gamut from simple keypairs (Nostr, Scuttlebutt) to URIs pointed at HTTPs URLs hosting profiles (ActivityPub) to more complex models which use onchain primitives like NFTs (and more recently ERC-6551 extensions e.g. Lens v2).

Farcaster is a great example of these techniques. A Farcaster account represents a distinct entity on the network. Each account has a unique numeric identifier called a Farcaster ID (“fid”). Identities are issued and managed onchain using an Ethereum contract called the IdRegistry. Users make a transaction to the IdRegistry to get a new fid. The address that owns the fid is the user's custody address. The IdRegistry ensures that fids can be transferred between addresses and that no two addresses have the same fid. Farcaster also extends this namespace to support ENS names that are issued onchain or offchain. A signed proof must be submitted to the network to claim a username.

ActivityPub, on the other hand, identifies every user by a unique URI, typically 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 like ‘@[email protected]’.

Lens and CyberConnect instead manage user profiles as NFTs.  In the case of Lens, a user address holds a ProfileNFT, and it is possible for a single address to hold multiple ProfileNFTs. Each Profile NFT encapsulates the entire history of a user's activity, including posts, mirrors, comments, and other types of content that they have created. Additionally, Profile NFTs have a FollowModule, which is essentially a set of rules that governs how different accounts can obtain Follow NFTs. These Follow NFTs serve to document the connections between accounts and the primary profile directly onchain. There are also handles that can exist and can be minted separately from profiles, and can be linked and unlinked from one profile to another. Handles exist in their own namespaces (e.g. lens/@alice).

Data

Data is arguably the most important feature of decentralized networks, since its creation and standardization is what enables these systems. The most common technique for managing data here is the use of standardized formats like JSON and common relationship objects (e.g. likes, follows). Core data objects typically include:

  • Actors & Objects: Defined "actors" (eg. users or groups) and "objects" (eg. posts or messages).

  • Publications: Posts or comments are encapsulated as "Publications," often linked to external content via URLs.

  • Content in Append-Only Logs: Logs where each entry, be it a post or update, is a discrete content item, sequentially added and stored.

Let’s dive into a couple examples of how this works using specific protocols.

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

Within ActivityPub, entities are categorized as "actors" (often user accounts or groups) and "objects" (content or actions like posts or likes). When an actor performs an action on an object, it creates an "activity" such as "Create", "Follow", or "Like".

Web3 social graphs take many of the core ideas of ActivityPub but apply them onchain. Lens Protocol, for example, introduces "Publications," which encapsulate a variety of user-generated content such as posts, mirrors, comments, and other forms of media. Each Publication is associated with a ContentURI, directing to the specific content stored on a decentralized protocol like IPFS or Arweave, or alternatively, on a centralized storage service such as AWS S3. This configuration ensures that a user’s profile and all associated publications are securely stored in their personal wallet, moving away from reliance on centralized databases.

Furthermore, Web3 enables a more straightforward approach to monetizing user content and influence compared to the Web2 framework. Users can charge for the minting of Follow NFTs, or they can integrate Collect Modules with their Publications. This latter option allows them to receive a fee for minting of NFTs linked to the ContentURI of their publication. In addition to these features, Lens Protocol offers a GraphQL API, serving to mask the blockchain components from frontend interfaces and consequently, delivering a more user-friendly experience than previous decentralized social networking attempts.

Ultimately, many of the decentralized social networking protocols create append-only data structures which are authenticated by user keys. For example, on CyberConnect each piece of user-centric data is represented as a data stream where updates are only allowed by the data owner. 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, collects, comments, and subscriptions.

Scuttlebutt similarly uses an append-only log. Each user has their own log where every new message or action is appended to the end after being signed by the user identity (i.e. the associated Ed25519 key pair). It also supports the sharing of binary data, referred to as "blobs." These can be images, videos, or any other binary content. Blobs are stored separately from the append-only logs, but references (hashes) to these blobs can be included in the logs.

For Farcaster, messages are public updates like making a post, following someone, or adding a profile picture, and these messages are encoded as a protobuf and must be hashed and signed by the account's signer. Users can publish messages to Hubs as long as they have sufficient storage. Hubs check the validity of each message's signers before accepting them.

Storage

Early approaches to data storage for decentralized protocols were largely offchain, although reminiscent of onchain consensus. Scuttlebutt, for example, uses a peer-to-peer gossip network, placing the onus of storage on the user’s local device. This approach ensures data sovereignty, as users have complete control over their own information. However, it also means that data availability is dependent on the user’s device being online or other peers in the network having a copy of the data. Over time, to manage storage space, some Scuttlebutt clients might need to implement garbage collection strategies to prune old or less relevant data.

An alternative to this peer-to-peer approach comes in the form of servers storing data, although with redundancy compared to traditional media platforms. Matrix as an example has multiple homeservers store copies of room histories and synchronize with each other. When a user sends a message (or any event) in a room, their homeserver broadcasts that event to other participating homeservers, which then store and forward the event to their connected clients. Similarly, ActivityPub has 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 instance, Mastodon, a popular ActivityPub platform, uses a PostgreSQL database.

Protocols like Cyberconnect, Farcaster, and Lens have embraced blockchains for storage. The use of on-chain storage ensures that data is immutable and verifiable, providing a robust foundation for decentralized applications using underlying consensus mechanisms for syncing state. However, this approach can lead to scalability challenges, as every piece of data needs to be stored onchain, potentially leading to high transaction fees and slower retrieval times.

This has led many web3 social protocols to experiment with hybrid approaches that use onchain storage for less frequent actions (e.g. profiles, subscriptions) and offchain storage for high frequency events (e.g. likes, reposts, comments) or batch-uploading data onchain at frequent intervals with offchain storage used as an interim stopgap.

CyberConnect, in order to efficiently handle the frequent updates between user connections, employs a hash-linked list in a decentralized data store. On initiating a connection, an 'operation log' is created. Subsequent state changes, like toggling between following and unfollowing, are added as new nodes to this log. While these updates are initially stored on a central server, they are periodically batch-uploaded to decentralized storage platforms such as Arweave or IPFS. For quick data retrieval, the nodes in the operation log are stored centrally. However, users can independently verify data integrity by navigating through this hash-linked list. Even with the dependence on a central server for some data queries, CyberConnect's system is designed to be sufficiently decentralized while also offering high performance.

Farcaster similarly uses a hybrid approach: onchain contracts are used for infrequent actions where consistency and decentralization are important. Accounts, usernames, storage, and keys are managed using a series of Ethereum contracts. Offchain systems are used for frequent actions where performance is critical. Messages created by user accounts are stored and propagated on the peer-to-peer network of Farcaster hubs.

Discussion

Decentralized social protocols are poised to revolutionize the user experience in digital interactions. The accelerated adoption of public-private keypairs, propelled by both web3 traction and as a proactive measure against AI-generated content, will facilitate a broader understanding and familiarity with identity primitives in this context, and continued moderation and data capture at web2 social media companies will openly push more users to look elsewhere. We expect an accelerated adoption curve for these protocols.

To foster the evolution of novel applications, there is a pressing need for protocol developers and open-source contributors to venture beyond the basic data types and relationship objects currently employed at the infrastructure layer. While the existing primitives adequately encapsulate the functionalities of conventional web2 social media, there is immense potential for expansion and innovation. The majority of protocols under discussion here inherently support extensibility within their systems, providing a solid foundation for future developments and open-source contribution.

However, it is crucial to underline the importance of interoperability. While frontend developers are capable of augmenting functionality independently, doing so might detract from the collective benefits of the system if the enhancements are not interoperable with other applications built upon the same underlying protocol. Ensuring compatibility and seamless integration across various applications is vital for the long-term success and adoption of decentralized social protocols.

In the realm of data storage, the emerging consensus within web3 social protocols leans towards a hybrid approach. Given the high volume of social content and engagement, it is pragmatic to allocate high-value assets such as identity and primary content to on-chain primitives, while relegating lower-risk content like likes and reactions to off-chain solutions. This balanced approach not only preserves the integrity and security of crucial data but also provides a user experience reminiscent of traditional social media platforms.


Decentralized networks hold the promise of transforming 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 landscape. Moreover, the decentralized nature of these networks serves to democratize access to information and resources, mitigating the risks associated with centralized control.

If you are building in decentralized or federated social media, please reach out to us.