5 min read
Overview
A new decentralized social network called Farcaster is gaining traction for its integrated web3 architecture and its unique twist in-app experiences. Farcaster, built on Ethereum, allows users to create public social profiles and communities to interact with others.
In this guide, you will learn more about Farcaster, how it is designed, and how it compares to other social networks like Meta and X. Let's get started!
Prefer a video walkthrough? Follow along this video to learn about Farcaster and architecture.
What You Will Do
- Learn about Farcaster
- Gain fundamental knowledge of Farcaster's architecture
- Learn about Hubs and how data is stored on Farcaster
What You Will Need
What is Farcaster?
Farcaster is an innovative, open-source, decentralized social network that sets itself apart from centralized social networks like Meta or X by giving users complete control over their data. Unlike these centralized platforms that retain ownership of user data, Farcaster empowers its users with direct data ownership.
While Farcaster shares similarities with traditional social networks, it introduces new terminology:
| Farcaster Vocabulary | Equivalent Common Social Media Term |
|---|---|
| cast | post |
| channels | groups |
| frame | web app |
Key points about Farcaster include:
It functions as a standard social network, allowing individuals to:
- Set up an account
- Share content
- Engage with content shared by others
These functionalities align with the general expectations of a social network. However, Farcaster distinguishes itself through these integrated web3 aspects:
- An Ethereum (EVM) address is required to create a Farcaster account. This address will be linked to your account and used to sign messages and publish them on the Farcaster protocol (unlike the traditional username/password method). Messages of any activity identified as posts, replies, follows, etc.
- User account data like profile details are stored on-chain. This is done via a smart contract (e.g., Id Registry) deployed on Optimism mainnnet. Other data, like Casts, etc., are stored off-chain on Farcaster's storage network called Hubs.
- Usernames can be managed on-chain via ENS, ensuring users have sovereignty over their identity compared to centralized entities, who can revoke usernames at their discretion. Anyone can call the ENSRegistry contract to resolve a username to its custody address.
- Users can create and embed decentralized applications within their posts (e.g., a mint NFT button, 1-click DAO vote, etc.). - Users can create and embed decentralized applications within their posts (e.g., a mint NFT button, 1-click DAO vote, etc.). These are called "Frames", and they must comply with the OpenGraph in order to render properly in a Cast. Some popular frames already built by others include @cookies, who built a seamless checkout experience in a Frame powered by Coinbase Commerce and $DEGEN, which is an ERC-20 token airdropped to the Farcaster community via BASE chain.
- The absence of a single entity owning the underlying data means that anyone with a Farcaster account can run a Farcaster node (aka Hub) and read/write data.
Farcaster's unique features are supported by:
- Specific smart contracts, each performing distinct functions to facilitate the decentralized experience
- Hubs, which refer to the open-source, decentralized, distributed peer-to-peer nodes that store and serve Farcaster data
Farcaster Architecture
As discussed previously, Farcaster stores some data like account creation on-chain and other data like Casts on nodes referred to as Hubs.
Here is a high-level view:
Let's dive into more of the smart contracts utilized.
Farcaster utilizes three smart contracts (deployed on Optimism mainnet) to facilitate on-chain operations:
- Id Registry - This ID registry contract allows users to register, transfer, and recover accounts. It is tied to a
fId, which is tied to the Ethereum address used during account creation - Storage Registry - The storage registry contract keeps track of accounts and their storage rents. This is the same rent a user pays when creating an account and is used for their interactions (e.g., Casts, replies) on the Farcaster network.
- Key Registry - The key registry contract keeps track of keys registered to apps. This controls if an app can conduct activity (e.g., post, follow) on the user's behalf
To learn more details about each smart contract's functionalities, check out the documentation, and view the source code here.
Hubs
The network of nodes storing and serving Farcaster data is called Hubs. This distributed, peer-to-peer network of nodes stores and validates the entire state of Farcaster (both on-chain and off-chain data) and communicates with one another to keep the state of Farcaster up-to-date.
Since Farcaster is open-source, any user can run their own Hub and be able to read/write data from Farcaster via the API. Current implementations of Hubs include Hubble (written in Rust and Typescript). Let's first dive into storage and how it's stored; then, we will dive into the message lifecycle and how it's validated/stored on a Hub.
Storage
In order for an account to interact on the Farcaster network, it must first pay rent. This is usually a once-a-year fee that covers all the activity an account may conduct, such as casting, replying, following others, etc.
Each type of message gets allocated some rent, and any messages published after this rent amount has been exceeded result in the oldest message being pruned (by a Hub). Users can continue using the Farcaster protocol once the rent has been exceeded due to Hubs pruning and controlling the network load.
Now, let's talk about messages and how they get stored on a Hub.
Message Lifecyle
The sync process for a Hub contains a two-phase process - gossip and diff sync. Let's outline how it is used in the lifecycle of data being stored/served on Hubs:
- An account creates an interaction (e.g., Cast, React, Link) by signing the message
- The message gets stored on a Hub and gets validated (e.g., is the signature valid? does it meet Cast requirements?)
- The message is checked (async) for conflicts across storage and account limits (e.g., was the Cast deleted; a copy exists; does the account contain enough rent?)
- If valid, the Hub propagates this message to other Hubs on the network (i.e.,
gossiping) - Periodically, a Hub will run
diffsync to find messages that have been dropped and efficiently recover them
Note that running a Hub requires a minimum hardware requirement and does not generate revenue for users running the node. To control bad actors, Hubs monitor peers and score their behavior, ignoring bad behavior if detected. To learn more, check out the Hubs documentation.
Additional Resources
Final Thoughts
Well done! You now have a fundamental understanding of Farcaster and how it operates. To compound on your newly gained knowledge, be sure to check out the guide on building [Farcaster Frames], then share your custom Frame by tagging us @QuickNode!
If you have questions, check out the QuickNode Forum for help. Stay up to date with the latest by following us on Twitter (@QuickNode) or Discord.
We ❤️ Feedback!
Let us know if you have any feedback or requests for new topics. We'd love to hear from you.