Notes on Farcaster
Future Proof Notebook, Volume 1Written by Val, Co-Founder of Future ProofAugust 2, 2023Conclusions
Farcaster is a system design for a social network that can be run in a decentralized way. It specifies user generated content and actions on that content called "deltas" and how servers called "hubs" can process and store these deltas so that any user of the social network can interact with any other while having the ability to use different applications. For example, Merkle, Discove, and Purple are three different apps all built on Farcaster. If Mauve uses Merkle, Dane uses Discove, and Pritha uses Purple, they can all still view and react to each other's content. Overall, Farcaster is kind of like Secure Scuttlebutt (SSB) but simpler, it's got Matrix protocol vibes, and it's tied to Ethereum.
A big red flag is that there's no team page. That's like the equivalent of building "E2E encrypted" closed source software--can't really trust what is happening behind the scenes when the team won't say who they are. When a team doesn't show their face it generally means they think people will call them out for harmful opinions/politics or lack of diversity or both.
Dan Romero is the creator and that is obvious from their website and socials. I guess he's the founder of Warpcast which is building Farcaster? Quite sure someone named Varun Srinivasan also works there and I think these are some other people working there but I'm not sure: https://github.com/orgs/farcasterxyz/people
Not much info on why Farcaster was created except for this line in the Overview section of their docs in reference to centralized social networks: "Users and developers have restricted freedoms and become subject to unwelcome moderation and privacy violations." They want to "sufficiently" decentralize to avoid these things.
Much of the way the system works is what you would expect. It's not very fancy, which I think is a good thing. It also doesn't seem super tied to feed based social media applications, which is super nice. That was my hesitation with SSB, though it is a flexible protocol they framed it very much to be for microblogging. Farcaster doesn't use that framing, though so far the apps I've seen are just that--Twitter clones. It makes simple tradeoffs that match social norms but tend to be the opposite of what computer scientists and tech nerds want to build. We want to build sophisticated systems and make them as perfect as possible. Users don't care about that. For example, right now deltas expire after 1 year or if a user exceeds some threshold for the amount of deltas allowed by a single user. That's not how most social platforms work today but it is totally sane and makes decentralization more realistic by lowering the burden of hub operators.
The system is tied to Ethereum at least at the identity layer and the security model stems from here. I don't think that equals decentralization. Who controls these smart contracts? Who can modify them? Will it be a DAO at some point? Who gets to be apart of this DAO? Is it people with money who already know about Farcaster and maybe have the time to learn about the Farcaster ecosystem? Who said Ethereum was decentralized anyway?
I can't really figure out who Farcaster is for. I think of it kind of like a more resilient Reddit because it seems like they are really targeting this multi-client experience but of course purport to be building the sytstem so that users can't be rugged when it comes to the content they create and getting it to their followers. My guess is right now it is used by web3 people. Just experimenting, having fun, and hopefully getting a bag along the way. I went to warpcast.com a second ago and the first post was someone "announcing" their decentralized DNS product. (DNS is already decentralized but... keypairs, Ethereum, on-chain, something).
Final word for now: I want to build on it, but not another Twitter/X clone.
Notes
Introduction Video
They define a decentralized social network as one where you can use different client applications to communicate with the same group of people. Was Reddit decentralized? It had different clients because they had a public API, but I'd still very much consider Reddit centralized. I think a decentralized anything should mean, no single point of failure. This different client app thing does not prevent a single point of failure.
First problem they identify is identity. Across different client apps a single person should be able to use and control a given digital identity in a "decentralized" way. Second problem is authentication. Users in the system need to have a way to confidently know that a message they see was created by the person that it says created it. Because the messages are not guaranteed to come directly from the author. So we need a way to know or identify if they have been tampered with or not. An assumption is made here that random people are accessing messages potentially designated for a specific person. I wonder how deep that goes in the Farcaster implentation. If they have DMs, who handles those? Third problem: availability. Data created in the social network is available no matter what client app a user is using. They put this is the context of the fact that the amount of data can become so large that a single app can't find a way to display all of it or find a way to store and search through all of it then present it to the user in a reasonable amount of time. (Lookup data indexing for more context on this.) Problem four is consistency. If there are conflicts in the data, for example from duplicated data that would violate the rules of the app, but slip through so that different people get different copies of the duplicated data, we want a mechanism for resolving those conflicts so that everyone has the same state, or view of the data. As an aside, the Holochain team consistently tries to explain this away by saying, well you can't have conflicts because you validate state yourself first, which is such an annoying answer because it is misleading. The real answer in Holochain is you write your app based on how much you trust your peers and determine your own conflict resolution.
Trustworthy Identities Video
Farcaster uses smart contracts on Ethereum to register identities. As of today I think they are still on Goerli testnet. One contract makes a Farcaster ID, fid to an ETH address. The other maps an alias or human readable username to an ETH address. Fids are required, usernames are optional. Clients resolve both it seems. Fids are the decentralized identifiers while the alias I think could rely on any other name registry service. Not sure how swappable they are but because they map to the ETH address and not the fid it seems as if clients can pull from any registry their users are using.
Authentication Video
They use asymmetric (public-private) keypairs underlying an ETH address to sign messages and across devices they have a sort of delegation system where a new keypair is generated specifically for that device and the identity holder signs a custody message saying the device's keypair is signing on my behalf. So when other users authenticate they walk a signature chain to confirm the author.
Account Recovery Video
Your primary account address can transfer ownership of an fid to another address but can also add a recovery address. The recovery address can request transfers of ownership with a 7 day escrow period before it completes unless the primary account issues a cancellation before that. Anyone could contorl that recovery address so it could be the same owner or a third party service.
System Overview Video
Every node/server is a hub that keeps a copy of all the data on the network. Proxies are the servers that get the data from the hub and do the fancy stuff with it like organize, categorize, index, and use some algo to build a feed for client apps that use its API. L1 - Identity layer (registry on ETH). L2 - Data layer (storage, syncing, availability). L3 - App layer (retrieving, indexing, API for clients, message creation).
Delta Graphs Video
Every user action is a delta (post/cast, like, recast, reply) and hubs hold all the deltas. Any deltas that conflict are resolved by a merge algo (e.g. you can't have a user like and unlike something simultaneously so the algo picks one and discards one) and the hubs should use the same merge algo so that when they sync deltas they have the same state.
Merging Deltas Video
The merge algo they were talking about is, hash every delta, drop duplicates, use timestamp as tiebreaker first, then fall back to the greater hash as the tiebreaker.
Delta Types Video
Casts/posts, reactions (reply, like), amps (make someone else more visible to your followers), verifications (two way signature to prove a link between an ETH wallet and your farcaster wallet which I'm guessing is your fid account), userdata (profile/bio), signers (aforementioned primary keypair and delegate keypairs). Delete a delta with a deletion message. Hubs store deltas by category with deletions there too and each category has a CRDT acting on it (the merge algo we were talking about again).
Pruning Deltas Video
They believe if hubs have to store too much data it will lead to centralization because costs increase. The two forms of pruning are time and amount. Hubs can discard deltas over a year old and have a per user size limit for the amount of deltas they will store.
Sync Video
What you would expect. Flood based gossip using RPC over UDP and periodic "diff sync" because gossip is fast but not reliable so any missed messages can be sent by comparing merkle trees of all data. The same process is used when a new hub is introduced.
Direct Casts Video
They want to do DMs in a way that is secure (message is only able to be read by intended recipient), reliable (recipient actually gets the messages), useful (read receipts, reactions, hyperlinks, etc.), and open (users can be on different clients). They say no one has achieved all of this but I feel like Matrix is exactly this.
Secure Messaging Video
Antiforgery and end to end encryption. Forward secrecy: if a secret key used by two parties is compromised, the attacker can only use it to read past messages, not future messages. Break-in recovery they describe as basically the same thing except mention self-healing. So no idea what that is really. Metadata privacy: no public or leaked information about the fact that two people are talking at all, how frequently, what times of day, etc.
E2E Encryption Video
They just explain Diffie-Helman.
Forward Secrecy Video
Forward secrecy. They misspoke in the previous video. It's actually using a key to generate a new key so that every new message is encrypted with a different key dervied from the previous key. So this means both parties can deterministically generate the needed symmetric key and having a key doesn't mean you can decrypt something that was encrypted with a prior key. So an attacker could read future messages but not past ones.
Break-in Recovery Video
To prevent an attacker from reading future messages a new public/private keypair is created, I think for each new message? To do Diffie Helman again and use the resulting shared secret as an input to the key derivation for the next key. They also do this twice over with two different keychains per person, one for receiving messages and one for sending messages. This is where the video does a better job explaining than my notes will.
Double Ratchet Video
Root keychain is used to generate the sending and receiving chains. This is what Signal does. Let's dive into Signal next!
Triple Diffie Helman Video
Each person trying to DM generates 3 keys and DH is done between the 6 keys to generate a single secret that is the initial key input into the root keychain for the ratchets. A chain of trust is established by signing these 3 keys with the key used for the farcaster id. So each party can be confident the person they are establishing their encrypted chat with is who they think it is.
