# Architectures of Decentralized Social Networks

## Introduction

In this essay, we dive into the architecture of **Decentralized Social Networks (DeSoc)**, focusing on their mechanisms for storing and managing network states and user-generated content. We explore three distinct architectures in DeSoc: **Lens Protocol**, which employs blockchain technology; **BlueSky**, which uses a distributed system approach; and **Farcaster**, which combines both blockchain and distributed systems.

## Lens Protocol: A Pure On-chain System

Lens Protocol (Lens) adopts the blockchain approach to DeSoc. Users in Lens own their social graph entirely on-chain, stored through smart contracts. The main concept in Lens is the creation of a **Profile** for each user, which is an NFT.

The **LensHub** contract acts as the entry point for interacting with the network. At first, you can invoke the contract to mint your Profile, and then you can call its functions to publish content, update profile data, and follow other users. Your data and content will be stored in the Profile through on-chain mappings. For example, you can access one of your publications by calling a get function that specifies your `profileId` and `pubId`. Also, a Follow NFT will be created when you first follow another user, and it stores your relationships. Lens emphasizes modularity, allowing different **modules** [1] to be plugged into the system to extend functionality.


The above describes the live v2 version of Lens. The upcoming **Lens Network** aims to enhance scalability and reduce costs using zkSync technology. This approach involves two main solutions:

- **Validium**: Uses zero-knowledge proofs to compress state and store only proofs on-chain, while offloading state data to off-chain data availability (DA) providers.
- **Volition**: Based on Validium's approach added another transaction type that stores the state on-chain to offer high security, which can be useful for financial transactions.


## BlueSky: An Off-Chain Federation System

BlueSky adopts a federated network that emphasizes decentralization without relying on blockchain technology. The **Federation** network is composed of multiple **Personal Data Servers** (PDS) that can be either internally operated by BlueSky or externally self-hosted by anyone. These servers store user data and communicate within the federation to synchronize information. Also, there are other components including **Relay**, **Feed Generator,** and **Appview**. Relays monitor PDSs and aggregate data, which is then processed by feed generators. These generators apply their customizable algorithms to create feeds that are pushed to the Appviews, which is the service that lets clients retrieve data for end users.


## Farcaster: Hybrid On-chain and Distributed System

Farcaster (FC) presents a hybrid model where vital user states like user identifiers are stored on-chain, while content and other data reside in a distributed off-chain network known as the **Hub Network**. This setup allows Farcaster to leverage the security of blockchain for essential operations while utilizing a distributed system for high-throughput social interactions.

Farcaster's on-chain part consists of only three smart contracts. **KeyRegistry** lets users register and obtain a `fid`**,** which serves as a user identifier on FC. **StorageRegistry** lets users rent `storage`, and to use FC, you must rent at least 1 unit of storage to use FC. Each unit allows for 5k casts (posts), 2.5k reactions (likes or comments), and 2.5k follows. **IdRegistry** lets users add a `signer`, which is a public key that can represent the user to send messages. This is somewhat similar to OAuth; if a user wants to use a new Client, it will request the user to add a `signer`.

On the other hand, the off-chain part Hub Network consists of **Hubs**, which are nodes that store replicas of network data and pass messages to each other. A client connects to a Hub to access the data requested by users and to send messages initiated by users. For example, when a user sends a cast, this cast is packaged into a message, signed with the user's private key, and then sent to the Hub. Upon receiving it, the Hub verifies the legality of the message; if deemed valid, the message is broadcast to other Hubs, allowing other clients to access this cast.


## Comparing The Three Systems

The primary difference between these architectures lies in their approach to data storage:

- **Lens Protocol** is fully on-chain, emphasizing complete decentralization but incurring higher transaction costs and slower interactions due to the nature of blockchain. They’re addressing this issue by leveraging ZK technology and DA providers to move network states off-chain.
- **BlueSky** opts for an off-chain federation network that allows for high scalability and zero cost to interact with the network, but it also requires more resources to operate a highly distributed network consisting of many PDSs.
- **Farcaster** combines the security and interoperability of blockchain for critical states with the scalability of an off-chain distributed system for higher throughput social interactions, offering a balanced approach with lower interaction costs and scalable performance.

## Further Readings

1. Lens Protocol Modules:
1. Follow Module: Executed when a user follows another profile.
2. Action Module: Activated during interactions with publications.
3. Reference Module: Used during commenting or mirroring publications.
2. [Building Bluesky: a Distributed Social Network](https://newsletter.pragmaticengineer.com/p/bluesky)
3. [Farcaster CRDT](https://github.com/farcasterxyz/protocol/blob/main/docs/SPECIFICATION.md#3-message-graph-specifications)