The Case for Snapchain Minimalism

Farcaster Pro is launching next week, and at some point it will introduce features like 10,000-character casts and up to four images per cast. These enhancements will require a protocol upgrade.

While I believe in the core idea of a Pro subscription, for me, this reopens a (friendly!) long-standing debate I have with the Merkle Manufactory (MM) team: I believe new types of content should be stored outside the protocol.

The Core Idea

I believe that we should store as little content as possible on snapchain, and design the standards that will allow Farcaster content to be stored externally.

Instead of baking support for content types (such as long-form text, code snippets, MP3 playlists, photo reels, geo-tagged casts, etc.) into the protocol, we should treat these as external resources, referenced by the protocol, but hosted elsewhere.

There are many ways to implement this, ranging from quick-and-dirty hacks to clean, modular solutions. I would argue for a new type of embed urls that point to a well-defined json, but I don’t want to focus on the technical details here.

Instead, I’ll explain why this approach deserves serious consideration, and why it should serve as a guiding principle for protocol development.

1. Permissionless Development

By moving new types of content outside the protocol, we allow anyone to introduce new experiences without needing approval or access to the protocol maintainers.

Take 10k-character casts or photo reels, for instance. These could have been implemented without touching the protocol, if we had a standard for embedding external content into casts.

MM often argues that we should “wait for demand” before introducing new primitives. Now that they themselves want longer casts and more images per cast, the answer is suddenly: “Let’s change the protocol.” Could they have used an approach like lemon3 enclosures? Sure. But it feels “hacky” and inelegant, I agree.

Ironically, longer casts (1024 characters) were added a year ago as a quick change, in response to my proposal for external cast data. Back then, the promise was: “We’ll revisit the approach if there’s demand for it.” Well, now there is demand for even longer casts, but again we just change the protocol to fit a specific use case.

I'm critical to MM here, but I think they would benefit too. Actually, they would be the first to benefit, because they want to be flexible to try new features fast, and any snapchain change, no matter how small, adds a significant overhead. Their experiments would go to market much faster if they did not have to implement snapchain changes.

Side-note: External content doesn’t mean any content type will be supported by every client. For example, I can introduce a type of content (let’s say m3u playlists) that the Farcaster app does not support. But a well-defined standard will allow a fallback representation, and proper indexing.

2. Decentralization

Storing more and more content on the protocol means that the storage requirements to run your own hub go up, and fewer people can run their own hub. Offloading (new types of) content reduces the storage burden on Farcaster hubs.

Yes, relying on external content introduces some complexity. But that’s a fair tradeoff if it means more people can run hubs, and client (not just user-facing clients, but also agents, bots, analytics, etc.) developers can choose whether they need these external data.

After all, if no one is able to run their own hubs because of increased hardware requirements, and end up using Neynar APIs, what’s the difference if the API results come from the snapchain or other sources?

3. Storage Costs Separation

External content storage allows apps to charge for storage and bandwidth without affecting the protocol.

Want to build a photo reel app offering 1TB per user? Go for it—no protocol changes needed. Casts can simply embed a pointer to a JSON file listing the images. You can even ask users to pay for storage, and it makes sense to everyone. Want 8 or 10 images per cast? Sure.

Thinking of video uploads up to 2 hours? Build it. Host the video. Charge for hosting and bandwidth. No need for protocol-level intervention.

Wait. Are We Already Doing This?

Ironically, Farcaster already supports this model, but only for a very specific type of content: miniapps.

Miniapps are externally hosted, protocol-referenced applications. Developers love them, users love them. One could argue that the new Pro features could be built as miniapps that get special treatment by the Farcaster client -or any other client wants to do so.

We don’t need to cram every new content type into the protocol. Let’s use an extensible, permissionless architecture where innovation and experimentation is easy.

We are already familiar with the mental model of storing miniapps externally. Why not do the same for content and get all the benefits mentioned above?