Forking the Farcaster client: what you actually need

Farcaster open sourced its client, and it is a real release. MIT licensed, web and mobile both in the repository, installed in a few minutes and built in less, running locally against the production API. That is a serious piece of work by the people at Neynar and Merkle.

The client is open. The API it talks to is not. That private API exposes roughly 600 unique paths, and more than 780 operations once you count methods per path. Not all of it matters: a good share is admin and internal tooling, plus wallet, swaps, tips and quests. A minimal client could work against far less, and it would still be a lot of surface area.

Origins are allowlisted. Localhost works, and so do farcaster.xyz and warpcast.com. That check is browser level, which means it is CORS, which means you could proxy around it. You would also be routing around a control that is there on purpose and can be closed whenever they choose.

So you can fork it, run it, and change whatever you like. The problem is that there is no backend to point it at.

Snapchain stores protocol messages: casts, reactions, follows, profiles, verifications. It does not store DMs, notifications, sessions, feeds or search. Generating a home feed means reading follows, fetching casts, merging, sorting, populating profiles, counting reactions, resolving embeds and paginating. Snapchain does none of that, so you need an indexer. Neynar sells one. Building your own is not easy, and it needs real resources and ongoing maintenance that get harder to budget as usage grows.

Three layers, then. Snapchain for protocol data, an indexer to make it queryable, and a product backend for DMs, auth, notifications, search and the catalog. A client needs all three.

What the open client gives you is the measurement. You can point at those 780 operations and see exactly how much product sits between the protocol and an actual app.