Original author: 1kx
Original compilation: Luffy, Foresight News
Driven by commercial motives, corporate-controlled social media platforms emerged and dramatically undermined the initial hopes for a participatory culture online. Network information technology should fundamentally democratize cultural production, but today, these profit-driven platforms limit and shape online behavior - likes are not an expression of gratitude for content, but a commercialization tool.
Alternative social media platforms built on decentralized technology and federated protocols recreate the original vision of social networking. Data is controlled by users and recorded in a decentralized database, the front end is driven by the community, moderation is an expression of community preferences, and algorithms are selected by users. This is an open source spirit that drives innovation.
The history of decentralized and alternative social media
Before the web became the center of business, entertainment, and social interaction, it was primarily a tool in the academic and military realms. Tim Berners-Lee had an egalitarian vision when developing the first network protocols: the Internet was originally designed to be a decentralized network where information could travel freely between nodes, No one individual has control and there is 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 provide tremendous value, they stray from the original decentralized ethos, resulting in 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 multiple independent servers or nodes that cooperate to form a social network, as opposed to a centralized platform where one organization controls all 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, interact with, and share content with users on other servers as if they were on the same platform. Examples of federation protocols include ActivityPub and OStatus, which power federation platforms such as Mastodon and PeerTube.
In a federated system setup, users can choose which servers they trust, they may migrate to a different server or set up their own, and they are given more autonomy. The term Fediverse (a portmanteau of Federation and Universe) is used to describe such a system. Fediverse started 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 recommended standard by the World Wide Web Consortium (W3C) in 2018.
In Web3, once data is ported on-chain, a federated social network is the default state of a decentralized system. The blockchain acts as a back-end server that stores content, and the front-end indexes this content and serves it directly to users. Identities are tied to the public and private key pairs that govern the users wallet, allowing users to easily verify any data or content they generate. Additionally, using on-chain primitives such as NFTs allows stored content to be bundled in metadata and serve as domain names or decentralized identities (DIDs).
Similar to how ActivityPub works, the Web3 protocol seeks to bootstrap the social graph through authenticated relationships between user nodes. Since any front end can index and serve this content, there is fierce competition at the front end layer and new features thrive. Additionally, since the data is stored on-chain, users can choose their preferred algorithms, and they can be incentivized to use certain algorithms to regain the value of their data. This, combined with 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 did not include all social protocols here, but selected some of the most popular social protocols:
identity/namespace
In a federated and decentralized social graph or network protocol, a namespace is a domain where user identifiers or other resources are unique. It is a method of distinguishing the resources or identities of one domain/server from another, ensuring that there are no conflicts and ambiguities when integrating or communicating across multiple domains.
Identity and association namespaces for different decentralized social protocols range from starting with simple key pairs (Nostr, Scuttlebutt), to URIs pointing to managed configuration files (ActivityPub), to using on-chain primitives such as NFTs (and more recently ERC- 6551 extensions to all scopes for more complex models such as 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 IdRegistry, and users initiate transactions to IdRegistry to obtain new fids. The address with fid is the users management address. IdRegistry ensures that fids can be transferred between addresses and no two addresses have the same fid. Farcaster also extends this namespace to support ENS names issued on-chain or off-chain. Users must submit 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 users profile and serves as their global identifier in Fediverse. To make these URIs more user-friendly, many ActivityPub platforms use a system called Webfinger. Webfinger allows users to have identities like @username@domain.com.
Lens and CyberConnect manage user profiles as NFTs. Taking Lens as an example, one user address saves one Profile NFT, and a single address can save multiple Profile NFTs. Each Profile NFT encapsulates the entire history of user activity. Additionally, Profile NFT has a FollowModule, which is essentially a set of rules that govern how different accounts obtain Follow NFT. These Follow NFTs record the connection between accounts and profiles directly on the chain. There are also handles that exist 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. lenses/@alice).
data
Data is arguably the most important feature of decentralized networks, as the creation and standardization of data is the foundation of these systems. The most common techniques for managing data here are using standardized formats such as JSON and common relationship objects (e.g. likes, follows). Core data objects typically include:
Subject Object: Define a subject (for example, a user) and an object (for example, a post or message).
Publication: A post or comment is packaged as a publication and usually links to external content via a URL.
Append only whats in the log: Each entry (whether a publish or update) is a log of discrete content items, added and stored sequentially.
Lets dig into a few examples to see how specific protocols work.
ActivityPub utilizes the ActivityStreams 2.0 data format, a JSON-based data structure, to represent various 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). C2S allows users to interact with their respective servers through client applications. In contrast, S 2 S facilitates communication between servers, enabling the robust federation properties of the protocol.
In ActivityPub, entities are classified into subjects (usually user accounts or groups) and objects (content or actions, such as posts or likes). When an agent performs an action on an object, it creates an active object, such as create, follow, or like.
The Web3 Social Graph borrows many of the 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 a decentralized protocol (such as IPFS or Arweave) or a centralized storage service (such as AWS S3). This design ensures that a user’s profile and all related publications are securely stored in their personal wallet, eliminating reliance on centralized databases.
Additionally, Web3 provides a more direct way to monetize user content and influence than Web2 architecture. Users can charge for the minting of Follow NFTs and can integrate Collect Modules with their publications. The latter option allows them to charge fees for minting 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.
Ultimately, many decentralized social network protocols create data structures that can only be appended and authenticated via user keys. For example, on CyberConnect, each piece of user-centric data is represented as a data flow, where only the data owner is allowed to update. Each update to the data is appended to the data stream by adding only a commit log, and the resulting data structure becomes a hash-linked data structure called a Merkle DAG. Data types include content, collections, comments, and subscriptions.
Scuttlebutt also uses an add-only log data mechanism. Each user has their own log, where every new message or action is appended to the end after being signed by the users identity. It also supports the sharing of binary data called blobs. This data can be images, videos, or any other binary content. Blobs are stored separately from append-only logs, but references (hashes) to these blobs can be included in the logs.
For Farcaster, messages are public updates, such as posting, following, or adding a profile picture, which are encoded in protobuf and must be hashed and signed by the account signer. As long as there is enough storage space, users can publish messages to the Hub. HUb checks the validity of each messages signer before accepting it.
storage
The data storage of early decentralized protocols was mainly off-chain. For example, Scuttlebutt uses a peer-to-peer gossip network to store data locally on the users device. This approach ensures data sovereignty as users have full control over their information. However, this also means that data availability depends on whether the users device is online or whether other nodes in the network have a copy of the data. To manage storage space over time, some Scuttlebutt clients may need to implement garbage collection policies to remove old or less relevant data.
An alternative to this peer-to-peer approach is the emergence of data storage servers. In the case of Matrix, multiple home servers store copies of room history and synchronize with each other. When a user sends a message (or any event) in a room, their home server broadcasts the event to other home servers, 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 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 use the underlying consensus mechanism to synchronize state. However, this approach can pose scalability challenges as every piece of data needs to be stored on-chain, potentially resulting in high transaction fees and slower retrieval times.
This has led to many Web3 social protocols trying a hybrid approach, using on-chain storage to perform low-frequency operations (e.g. profiles, subscriptions), using off-chain storage to perform high-frequency events (e.g. likes, retweets, comments) or using off-chain storage as A temporary expedient to upload data to the chain in batches at certain intervals.
In order to effectively handle frequent updates between user connections, CyberConnect uses hash linked lists in decentralized data storage. When a connection is initiated, an operation log is created. Subsequent status changes (such as switching between following and unfollowing) will be added to this log as new nodes. While 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 achieve fast data retrieval, nodes in the operation log are stored centrally. However, users can independently verify data integrity by browsing this list of hash links. Even though some data queries rely on centralized servers, CyberConnects system is designed to be fully decentralized while still providing high performance.
Farcaster uses a similar hybrid approach: on-chain contracts are used for low-frequency operations where consistency and decentralization are important. Accounts, usernames, storage, and keys are managed using a series of Ethereum contracts. Off-chain systems are used for high-frequency operations that rely on performance. Messages created by user accounts are stored and propagated on the Farcaster hubs peer-to-peer network.
discuss
Decentralized social protocols promise to revolutionize user experience in digital interactions. Accelerated adoption of public-private key pairs, driven by Web3, will contribute to a broader understanding of 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.
To facilitate the development of innovative applications, there is an urgent need for protocol developers and open source contributors to move beyond the basic data types and relational objects currently used by the infrastructure layer. Although the existing primitives fully cover the functionality 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 crucial. While front-end developers can independently enhance functionality, doing so may harm the overall good of the system if the enhanced functionality is not interoperable with other applications built on the same underlying protocols. Ensuring compatibility and seamless integration between various applications is critical to the long-term success and adoption of decentralized social protocols.
In the world of data storage, the Web3 social protocol favors a hybrid approach. By allocating high-value assets like identity and primary content to on-chain primitives, while allocating low-risk content like 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 that of traditional social media platforms.
Decentralized networks promise to transform interpersonal communication, information sharing, and community building. By prioritizing user autonomy, privacy and cultivating organic relationships, these networks are paving the way for a more equitable and user-centered digital environment. Additionally, the decentralized nature of these networks helps democratize access to information and resources, thereby mitigating the risks associated with centralized control.
