If I could have deleted Instagram and Facebook without losing my connections, I would have done so a long time ago. I suspect many others feel the same way, and this is the main reason there is so much excitement around decentralized social networks.
Joining Farcaster has been an exciting experience, because not only is the team building this vision of decentralized social networks, they are bringing users to the network in an intentional way and focusing on providing a great user experience as a prerequisite for providing full decentralization that is actually useful.
Varun Srinivasan, a member of the team building Farcaster, has been graciously providing video explanations of the protocol on YouTube.
https://www.youtube.com/playlist?list=PL0eq1PLf6eUdm35v_840EGLXkVJDhxhcF
These are my notes on the videos released so far.
Video 1. Overview
Social network: A network that enables users to perform actions on other users.
Decentralized social network: A network that enables users to perform actions on other users using different applications. This creates four potential core problems to solve:
1. Identity: Users must be able to use the same ID across different apps(decentralized IDs)
2. Authentication: ID must be verified
3. Availability: Data must always be available no matter which app is used to interact with the network
4. Consistency: Network state must be reliably shared between different applications
2. Trustworthy Identities
There are two options for creating identities:
1. Human readable usernames(@alice)
- Advantage: Good UX
- Problem: Allows claiming of untrustworthy usernames such as @google
2. Numeric identifiers
- Advantages:
- Issued from a smart contract
- Unlimited quantities
- Problem: Bad UX
Farcaster's solution: An optional username(Farcaster name) connected to a required numeric identifier(Farcaster ID)
- Allows the network to take away misleading Farcaster names(FNames) like @google
- Allows users to change usernames while preserving the same Farcaster ID(FID)
- Numeric ID == FID == primary ID
- Username == FName == governed namespace
This system requires 2 contracts to manage user identification
- Contract 1: Issues FIDs
- Contract 2: Associates FIDs with Fnames
3. Authentication
Problem: We need a way to know that a message from an FID actually came from that user
- Solution: Sign the message with a private key that corresponds to that FID
- Problem: You don't want the app to know your private key
- Solution:
Each app generates a separate key pair called the signer. By signing a message with their custody address, the user gives trust to the new signer to create messages on their behalf. Signatures created by the signing address are now linked to the original custody address.
4. Account Recovery
Problem: If the private key of the primary address is lost, the user loses account access
- Solution:
Users have the ability to associate a second address, known as the recovery address, with their FID. The recovery address can request a change to a different primary address, which takes effect after a 7-day delay. The delay period ensures that the recovery address only has access to identity in the absence of the primary identity.
- The primary address has the authority to instantly change to a new primary address.
5. System Overview
The Farcaster network is made up of 3 layers
- Layer 1: ID registry
- FIDs and their associated Fnames, stored on Etheruem mainnet
- Layer 2: Hubs
- Permissionless databases managing a decentralized conflict-free replicated data type(CRDT) which contains an entire copy of the network to provide full data availability
- Layer 3: Custom backend servers(optional)
- Take data from a hub and organize it in a way that optimizes the data for use by your client
Two ways to index data for clients:
- Directly from hubs:
- Fully decentralized because trust is delegated directly to the signer device
- From custom backend server: less decentralized because trust is delegated to the server which can be revoked or changed at any time, but allows for data optimization
6. Delta Graphs
Messages are used to represent actions that users take and hubs are used to store those messages
- A delta is an action, such as a cast, like, share, etc.
- Problem:
If Bob likes a post and then unlikes it, it creates a conflicting state. Hubs must handle this in a manner that keeps the state consistent.
- Solution: the set of deltas is combined using a specific set of rules to produce a valid social graph
- Social graph:
A set of vertices, representing users and actions, connected by deltas. This graph is produced from hub data using a specific set of rules. These specific rules, such as merge functions that resolve conflicts, ensure that all hubs produce the same social graph.
7. Merging Deltas
Merging deltas describes the process of combining conflicting actions, such as liking then unliking, to produce a specific and consistent result
- Every action contains a conflict ID(CID) describing the action, a state of true or false, a unique hash, and a timestamp
- Regardless of the order in which the hub receives actions, the one with the most recent timestamp wins the conflict and is reflected in the timestamp. This creates resilience to errors in the order in which messages are received by hubs.
8. Delta Types
Deltas are organized by hubs into three types:
1. Casts
2. Reactions(such as likes and recasts)
3. Amps: Endorsements of one user by another user
4. Verifications: Wallet signatures that verify account and token ownership
5. User data: Metadata about users, such as their bio
6. Signers: The first data type a user establishes, all other messages are signed with this original key pair
- Hubs store each delta type separately as a conflict-free replicated data type(CRDT)
Delete messages: Contain a reference to the hash of the original message it is deleting, as well as its own unique hash and timestamp
- Eradicates content of the original message so it is no longer stored on hubs
- This means that hubs don't store all messages, only those necessary to create a valid delta graph
Pruning Deltas
Hubs are run by two groups of users
1. Builders of Farcaster clients. Running their own hub ensures that their client can always publish to and read from the network
2. API services, which allow others to connect to the network without running their own hub(like Alchemy and Infura on Ethereum)
Problem: As hubs get larger, they get more expensive to operate
- This could result in more builders using APIs to avoid hub costs, which would result in more centralization
- People might spam APIs with low-quality messages, which could result in operators becoming more selective about who they allow to use their services
Solution: Limits on hub size
Delta Pruning: messages are removed from hubs after one year
- Messages can be archived with other services
- There is also an upper overall size limit to regulate extremely chatty users
- Ensures:
- That hubs remain small
- Each hub can be operated on a single AWS server
- All hub operators are on an even playing field -> Decentralization
Possible development: Allow people to pay for additional hub storage
10. Direct Casts
It is useful for a social network to enable both public and private messaging. Private messages on Farcaster are called direct casts
- Ideal characteristics of direct casts(DCs):
1. Secure: Private
2. Reliable: Confidence in the message's reception
3. Useful: Features such as automatic link previews, reactions, read receipts
4. Open: Ability to message between different clients
Problem: Openness and security are conflicting because different clients vary in their level of security
Solution: features to be gradually implemented over time, starting with security and reliability, then moving to usefulness and openness
- Security is already good but still improving
- Extreme reliability is in progress
- Usefulness and openness to be developed in the future
The first DC iteration is implemented only on the Merkle client until security and reliability are perfected. Messaging is not yet open between different clients.
Looking forward
As more videos are posted to the channel I will continue making notes and posting them here. This technology excites every fiber of my being, and I want to make sure that I have as complete of an understanding of it as possible so that I can contribute to making it what the world needs.