@wbnns
Spent some time taking a look at the Farcaster client now that it's been open sourced:
- Lots of good stuff! MIT license, web and mobile both in there. Installed in just a few min and built in even less, runs locally against the production API. Serious feat of development and S/O to folks that have worked on this at Neynar and Merkle
- The client code is open but the API isn't; the client talks to a private API w/ ~600 unique paths (780+ operations once you count methods)
- To be fair you don't need all of them & a good chunk is admin/internal tooling plus wallet/swaps/tips/quests; a minimal client could work with less but would still be a lot of surface area
- The API allowlists origins; you can run locally (localhost), and farcaster.xyz / warpcast.com work; this is browser-level though (CORS), so yes you could proxy it but you'd be routing around a control that's there on purpose and can be closed whenever
- So you can fork it, run it, change whatever you want etc locally but the biggest challenge is that there's no backend to point at
- Snapchain stores protocol messages: casts, reactions, follows, profiles, verifications but not things like DMs, notifications, sessions, feed, or search
- For example to generate a home feed a client needs to be able to read follows, fetch casts, merge, sort, populate profiles, count reactions, resolve embeds, paginate, etc. Snapchain doesn't do this, you need an indexer. Neynar sells one, or you build your own (not easy, also requires a lot of resources & maintenance especially with increased usage, which is hard to accurately budget for)
- So three layers: snapchain (protocol data), an indexer like Neynar (makes it queryable), a product backend (DMs, auth, notifications, search, catalog). The client needs all three if you want to build your own
- BUT with this open client you can now point at 780+ operations and see exactly how much product sits between the protocol and an actual app
Good opportunity to learn & build more
Folks that have expressed interest in taking the helm would benefit from sharing more details on how they'd technically operate and maintain this in a scalable way
It's definitely expensive, requires multiple full-time resources, needs some sort of healthy revenue model
There's enough public information now with the release of the open client to fully scope it out
p.s. a token is not a revenue model, it just buys more time to get back to where we are now
https://farcaster.xyz/manan/0xd058045c