Introduction
- Farcaster is a sufficiently decentralized social network.
- An open protocol that can support many clients, “just like email”.
Sufficiently Decentralized Network
- Where two users who want to communicate are always able to, even if the network wants to prevent it.
- Users have complete control over their identity (usernames), data (messages), and social graph (relationships to others).
- Developers are free to build applications and have unrestricted access to the network, and users must be free to switch between them.
On-chain & Off-chain Hybrid
- Hybrid architecture with on-chain and off-chain components.
- Identities are stored on-chain in an Ethereum smart contract.
- An Ethereum address controls this on-chain identity
- Can be used to sign off-chain messages on its behalf.
- Data is not stored on-chain
- Data is cryptographically signed by an identity
- Stored off-chain on user-controlled servers called Farcaster Hubs.
Accounts
- Each account has a unique Farcaster ID (fid).
- Farcaster IDs obtained by calling the Farcaster ID Registry (FIR) from an Ethereum address.
- Users can optionally acquire a Farcaster Name or fname from the Farcaster Name Registry (FNR) which issues it a unique name like @alice.
Signed Messages
- Signed Messages are tamper-proof and self-authenticating objects that are signed by an fid.
- A Signed Message has a message property that contains the payload serialized, hashed, and signed by the custody Ethereum address.
- The envelope contains the hash, signature, and the public key of the signing key-pair, which any recipient can use to validate that the fid signed the message.
- Each message also contains an fid to look up the custody address on-chain and a timestamp for ordering.
- They represent user actions like making a public post, reacting to something or adding metadata to their account like a username.
Applications
- Users can choose the type of application that best suits their needs and switch between them at any time.
- Self-hosted: application client that talks directly to a Farcaster Hub.
- It can publish new messages and view messages published by other fids.
- A more sophisticated application might add a proxy backend server that indexes data from Hubs.
- Search, algorithmic feeds, and spam detection features that are difficult or expensive to perform on the Hub.
Hubs
An always-on server that validates, stores, and replicates Signed Messages. Users select a Hub as their home and publish its URL on-chain using the FIR. Conceptually, Hubs form an L2 network for storing social data. Its consensus model has weaker consistency guarantees but stronger scalability guarantees because the network data is shardable down to the fid level.
Hub Architecture
- A Hub is a single-process daemon that receives data from clients, other hubs and farcaster contracts. It has three main components:
- Storage Engine - accepts valid messages, merges them into a consistent state, and persists state to disk.
- P2P Engine - gossips with other hubs to send and receive the latest messages on the network.
- Sync Engine - brings two hubs into sync when gossip messages between them fail to deliver.
Identity
- The Farcaster Identity system must ensure that user accounts:
- Can be owned in a secure, decentralized manner
- Are easy to recognize visually when using a social network
- Are quick and easy to set up (< 1 minute of work, ~ 10 USD)
- Are recoverable if lost, without compromising decentralization.
- Farcaster ID Registry (FIR), which issues new id numbers called fids, and a Farcaster Name Registry (FNR), which issues new usernames called fnames.
- Fids are secure, decentralized identifiers present in every message that are conceptually similar to uuids.
- Fnames, on the other hand, are primarily cosmetic modifiers that replace the fid at render time and can be changed at any time.
- Fnames are issued as NFT’s by the Farcaster Name Registry on a first-come-first-serve basis.
Username Policy
- Impersonation - If you register a username that belongs to a well-known public person or entity, your name may be deregistered. e.g. @elonmusk, @vitalikbuterin, @google or @whitehouse.
- Inactivity — If you’re not actively using a username for 60+ days, your name may be de-registered on request from another user, or at our discretion.
Replication
- The process by which Hubs accept new messages and determine a user’s state.
- Strong eventual consistency
- Hubs achieve this by implementing a CRDT Set for each message type which encodes specific validation and merge rules.
- This property makes Hubs highly available since they can go offline at any time and always get back into sync.
Casts
- A public message created by a user which contains text and can also embed media, on-chain activity or other casts.
- A cast without a parent is a top-level cast, which clients should display on the user’s profile or timeline.
- A cast with a parent is a reply to another cast, web URL or on-chain object which should be displayed in a thread.
Casts
- Casts form a series of trees where each root is a Cast or URI and each child node is a reply cast.
- Each tree can be rendered as a threaded conversation.
Actions
- An action is a public operation performed by the user on a target, which can be another user, cast or on-chain activity.
- Two types of actions are supported today: likes and follows.
- The protocol can be extended to support new actions easily.
- Conceptually, each action is an edge in a social graph.
Verifications
- Verifications are bi-directional proofs of ownership between Farcaster accounts and external entities.
- Verifications can be used to prove ownership of Ethereum addresses, specific NFTs, other social media accounts, or even domains.
1 | |