Overview
Farcaster is a sufficiently decentralized protocol for building social applications. Full decentralization means that two people who want to communicate can always communicate. It also means developers can access public data on the web without permission.
Design concept
There have been many attempts at decentralizing social networks, making different trade-offs in decentralization, scalability, and usability. ActivityPub chose federation, SecureScuttlebutt went the peer-to-peer route, and Peepeth is blockchain-based.
Farcaster borrows ideas from some of those projects but makes different tradeoffs. Its architecture is best understood as the product of three design decisions:
Flexible namespace
A user can have multiple usernames from different namespaces. Names may come from a decentralized namespace, which is censorship-resistant, or from a centralized namespace, which is free and easy to use.
A user's account has a unique numeric identifier 413241, for example , which maps to the username they own. Use Ethereum contracts to track identifiers, ensuring that two users can always find each other and communicate.
global status
Many decentralized networks are federated, but this breaks the guarantee of permissionless access to public data. It also complicates the developer experience by requiring developers to scrape many unreliable servers.
Farcaster stores all user data on a server called the Hub. Anyone can run a hub connected to all other hubs via a p2p network. When a user sends a new message to a hub, the message is propagated to all other hubs. Each hub must store valid data for all users or it will be excluded from the network.
Warehouse rental
Allowing users to store unlimited amounts of data harms the health of the network. Malicious users can create billions of spam messages, making it difficult for developers and users to use the web. It also makes it impossible to operate hubs designed for commodity hardware.
Farcaster charges users rent for storing data on the network. Pay an annual fee to the agreement to guarantee a certain amount of space on the hub. This curbs spam and encourages users to clean up less valuable data on the network.
concept
The protocol has five main building blocks:
Accounts, which represent users on the network
Username, pointing to the account
Signers, who post messages on behalf of accounts
Messages, which represent public updates to an account
Storage, which must be rented by the account to publish messages
Account
A Farcaster account represents a unique entity on the network. Each account has a Farcaster ID or fid, which is a unique numeric identifier such as 78213. Identities are issued and managed on-chain using an Ethereum contract called IdRegistry.
The user makes a transaction to the IdRegistry to get a new fid. The address that owns the fid is called the user's escrow address. IdRegistry ensures that fids can be transferred between addresses and no two addresses will have the same fid.
Username
A username can be used to identify or refer to an account. Users can connect multiple names to an account, but only one name can be active. Farcaster supports ENS names published on-chain or off-chain.
Farcaster at fcast.id. Each Farcaster account can request a free name. Users can also use names in other ENS namespaces, such as .eth. A signed proof must be submitted to the network to obtain a username.
Signed by
A signer is a cryptographic key pair used to sign a message. Each account can have multiple signers, which is helpful if you want to share account ownership or use multiple applications at the same time. Farcaster uses the KeyRegistry contract to manage on-chain signers.
The signer is the Ed25519 key generated off-chain. The account registers the signer by making a transaction to the KeyRegistry using the signer's public key. The private key can then be used to sign the message and publish it to the network.
Leave a message
Messages are public updates from Farcaster, such as posting a post, following someone, or adding a profile picture. The network supports multiple message types, each with its own properties, requirements, and semantics. Messages are stored completely offline on Farcaster Hub.
Messages are encoded as protobuf and must be hashed and signed by the account's signer. As long as there is enough storage space, users can publish messages to the Hub. The hub checks the validity of each message's signer before accepting it.
Storage
Storage gives an account the right to publish messages to the network. It is rented by paying an annual fee, similar to how you rent space on a web server. Storage is managed and tracked on-chain by the StorageRegistry contract.
Storage is measured in units, with a unit granting an account the right to store a certain number of messages. Anyone can pay StorageRegistry to rent a storage unit for an account. The price and size of each storage unit will vary based on supply and demand.
Architecture
Decentralized social networks have many requirements that are difficult to meet in a single system. Users must be able to create, own and transfer accounts in a decentralized manner. The messages they create must travel in near real-time and are often sent out in large numbers. These goals can only be achieved using a hybrid architecture that mixes on-chain and off-chain systems.
On-chain contracts are used for infrequent operations where consistency and decentralization are important. Accounts, usernames, storage, and keys are managed using a series of Ethereum contracts.
Offline systems are used for frequent operations where performance is critical. Messages created by user accounts are stored and propagated on the Farcaster hub's p2p network. Unlike blockchain, this network uses an eventual consensus model, allowing fast message propagation in exchange for a weaker consistency model.
Registration contract
The registration contract on the Optimism mainnet manages account identities, signers, and storage. There are three main contracts:
Id Registry - Issue fid to create a new account
Storage Registry - Track how much storage space each account has
Key Registry - Lets accounts register message signers
These contracts are simple in design, non-upgradeable, and have a limited life cycle. These contracts are deployed in trusted mode and only Farcaster can register new accounts. After a testing period, they will become permissionless so that anyone can register an account. This change cannot be undone.
ID card registration office
Id registry issues new Farcaster accounts to Ethereum addresses. Users can make transactions to obtain a unique numerical identifier for an address, known as a Farcaster ID or fid. An address can only hold one fid at a time, but they can be transferred freely. The account can specify a recovery address from which the fid can be transferred at any time.
Store registry
The storage registry rents storage units to accounts for an annual fee. Accounts must own at least one storage unit to post messages on Farcaster. Storage prices are determined by the contract in USD, but must be paid in ETH. Chainlink oracles determine exchange rates that are updated at most once in 24 hours. Prices, exchange rates, available units and the size of each unit are controlled by Farcaster and vary based on supply and demand.
Key Registry
A key registry allows an account to register a signer who can write messages on its behalf. Signers can be added or removed at any time, but once removed they cannot be added back. A signer can be added to multiple accounts. The signer is the Ed25519 public key and must be signed by the requester (i.e. the account requesting the key). This can be the user's account or the account of an application that wants to operate on the user's behalf.
deploy
Hub
The center authenticates, stores and replicates account messages to other centers. The application runs the hub to read and write to Farcaster in real time. Hubs run on commodity hardware and are conceptually similar to low-level high-performance data flows. Most applications should copy central data to a database for easy indexing and querying.
Each hub stores the entire global state or messages created by every account on the network. The maximum storage unit limit for storing the registry ensures that the size of the global state is limited. Unlike Ethereum nodes, hubs are ultimately consistent and may get messages out of order. This makes reading and writing very fast, but makes it more complex when interpreting changes.
Verify
When a message is received, it is hashed and its signature compared to the ID registry and key registry contracts. The message also specifies additional validation rules that are checked by the hub before merging.
Storage
When a message is validated, it is stored in the message set. Each message type has a set of rules defined for merging messages and handling situations where the number of messages exceeds the user limit. Typically, the oldest messages are eventually discarded. The rules are designed so that messages added in any order will always result in the same set.
Copy
When a message is stored, it is sent to other hubs through the libp2p gossip grid. Messages that do not arrive via gossip are retrieved using differential synchronization, a periodic out-of-band process. Differential synchronization compares the Merkle tree of message IDs between two hubs and retrieves missing messages. The center monitors peers and rates their behavior. A peer may be ignored by its peers if it does not accept valid messages, lags behind, or chats too much.
Implementation
Hubble - Hub implementation in Typescript and Rust
Username
Users can associate an ENS name with their account so that others can easily mention them in messages. Names must be fewer than 16 characters and contain only lowercase letters, numbers, or hyphens to prevent homograph attacks.
Farcaster currently supports two ENS names:
fnames, they are free and managed by Farcaster.
.eth names, which cost money and are controlled by the user.
Governance
Farcaster uses rough consensus and running code as its governance model. Change happens when someone makes a suggestion, gets support, and releases working code. Depending on the change, different groups need to be convinced:
Protocol developers, choose to merge changes into hubs and contracts.
Application developers, choose to deploy these changes to their hub.
Users, select the applications they want to use.
Consensus develops as people accept or reject the new code. Farcaster does not provide anyone with a binding voting process, official role or veto rights. Too much structure can create rigidity in the system, encourage politicking, and slow progress. Rough consensus biases action, encourages diversity of viewpoints, and maximizes decentralization, which is essential for long-term protocols. Most changes occur through the FIP process.
FIP
FIP, or Farcaster Improvement Proposal, is the process of building consensus around protocol changes. FIP is inspired by Ethereum’s EIP and Python’s PEP. Anyone can write a FIP to propose changes:
A process, such as a release schedule for an agreement
Standards, such as URIs for on-chain assets
An implementation, such as adding a new protocol function
Read more about FIP in FIP-0: Proposal to Propose a Proposal. The final list of proposals is below. Proposals were made on the discussion board and approved.
As soon as the project came out, V God released the latest news, indicating that V God has no regard for this project and will soon become the new leader.
Former Coinbase executive raises $30M for decentralized social network protocol, led by a16z
Merkle Manufactory has raised $30 million in a round led by Andreessen Horowitz (a16z).
The fledgling company, run by former Coinbase executive Dan Romero, is working to launch Farcaster, a “fully decentralized” protocol for building social networks.
A former Coinbase executive said on Tuesday that his company, Merkle Manufactory, raised $30 million in a funding round led by Andreessen Horowitz (a16z) to develop a social networking protocol called Farcaster.
Dan Romero, who left the exchange in 2019, announced the funding round in a post on his website. He explained that he and Varun Srinivasan, another former Coinbase director, began working together in 2020 on an idea called RSS+.
“Our goal was to build a trustworthy, neutral protocol that would allow users to have a direct relationship with their audiences and developers the freedom to build new clients without permission,” he wrote. “We went through several iterations and ultimately built Farcaster, a sufficiently decentralized protocol for building social networks.”
Standard Crypto, Elad Gil, 1confirmation, Scalar Capital, First Round Capital, Volt Capital, A Capital, Todd and Rahul's Angel Fund, Coinbase Ventures, Mischief, Ansa Capital, Haystack, Ribbit Capital, Chapter One, Multicoin Capital, Offline Ventures, Archetype , Canonical Crypto, Proof Group, Floodgate, Balaji Srinivsasan, 6529, Ray Tonsing and several other angel investors also joined the round.
