I love local-first infrastructure, that user can run at home, without depending on cloud providers or SaaS. My ideal software architecture is something:

• you can run it at home, on commodity hardware (i.e. everyone can do it, really decentralized, hard for a central authority to stop)
• requires no incoming network connections (because incoming network connections expose the local network to security threats most users can not mitigate, requires a stable Internet connection, and does not scale)
• and if it needs to share resources with the public Internet, it does so by publishing them as statically hosted assets, the cheapest (often free), most widely available Infrastructure-as-a-Service.

For example, my blog works like this¹: Everything is put together locally, then the static pages are hosted on a service like AWS S3, Cloudflare R2, netlify, etc.

A similar, but a bit more complex design is used by WDIM² (What Did I Miss?), a Farcaster³ miniapp that generates daily digests for its subscribers. In WDIM's case:

• the service runs locally, on a computer I have at home,
• it uses a Farcaster node that also runs locally,
• it checks a smart contract ("hosted" on Base L2) for subscription payments,
• and publishes the digest on S3.
• The miniapp is a web app hosted on S3 that leverages the Farcaster Miniapp APIs⁴ for payment and identity.

The core logic runs locally, on cheap hardware, subscription payments take place onchain, S3 is used for presentation.

Farcaster is an incredibly cool syncing machine that can enable local-first workflows: If you run a node locally, you have a full copy of the global state, ordered in blocks and updated almost instantaneously.

The application I'm most interested in? Enabling static blogs with functionality not possible right now, like comments, reactions, pingbacks, webmentions, etc., and all this using a local-first setup as described above.

Here's a half-baked outline of the idea. I'll call it SnapPub to make our life easier, but the name can change.

1. Notify the world that your feed has been updated

Knowing when an RSS feed has been updated is a big challenge: A typical RSS reader has to make costly (time- and resource-intensive) HTTP requests to poll feeds that rarely update.

Protocols like WebSub⁵ try to address it, but they need a service you run on a publicly accessible server.

The solution:

1. Advertise⁶ an fname or fid. This will tell the rss reader which Farcaster account to check for new updates.
2. When the feed has been updated, fname must post a FID-2⁷ cast with parentUrl=rssUrl (the body must be empty, and may be used for other features the future⁸)

Now an RSS reader/aggregator can watch the Snapchain⁹ feed for casts that match the above criteria. It doesn't matter how many blogs it needs to track, any blog that implements SnapPub will post there. This is a huge performance and scaling improvement.

And if the reader goes down, or doesn't want to maintain a process that filters the Snapchain feed in real time, it can check periodically for casts that were posted since the check. Snapchain nodes offer APIs that make all this very easy, like GetCastsByParent() and GetCastsByFid().

2. Comments, pingbacks, webmentions

SnapPub offers a way to comment on blog posts as a user, or even send a "mention" (similar to webmentions or pingbacks) when an other blog mentions a specific post.

• Any FIP-2 reply to the post URL (posted using Farcaster, or any other Snapchain client) can be treated as a post reply. Again, it's easy for a local backend to check for these replies, embed them in the post periodically, and republish the post (but without an RSS update).
• Webmentions and pingbacks can also be implemented as comments (linking to the source in cast's embedUrl)

A nice feature of this approach is that a blog does not need to update the static pages to include these replies, it can optionally link to a page like farcaster.xyz/~/urlconversations/<post URL> where users can see all replies to a post and join the conversation. This will require a Farcaster client that offers this functionality (the default Farcaster client does not, and given their focus in becoming a wallet I don't see it happening, but it could be done by someone else, like Cura¹⁰).

3. Likes

FIP-2 supports reactions to an arbitrary URL, so users can use Farcaster to like a blog post. In the same way the like any cast.

Bonus

Farcaster comes with many tools that can help fight spam. There is a social graph, there are a number of quality scores that can indicate if a user is spammy or not. All these features can be leveraged to filter comments. They can even be used to gate comments based on specific criteria (there is no way to prevent a user from commenting on Farcaster, but you can filter which comments appear in your blog).

It also comes with identity, which means every comment or like is attached to a username, an avatar, and social activity that can be used to enrich the presentation.

Concerns

The trajectory Farcaster has followed in 2025 is not very reassuring.

Practically, the network is centralized, and depends on one (or maybe two? I've asked many times but never got a reply) validators run my Merkle Manufactory and maybe Neynar. There is no guarantee they will not change their mind and shut it down, or close it in ways that would make this idea unusable, or that they won't be coerced to censor it. (The question is not "why", it's "why not".)

They have also been very selective on the features they add to the protocol, based on what they think brings value, but in other cases they may move so fast that may break clients. (I had this happen to me, when they added some user_data fields overnight, to support Farcaster Pro features.)

On the plus side, as long as their bet on social trading/wallet works, or they believe it has the potential to work, the network will be up and we can piggyback on it. The existence of clients from Base and Zerion, i.e. "big" teams that they respect, will probably slow down any quick'n'dirty changes like the ones introduced earlier this year. And, to be fair, many of my concerns around centralization can be addressed if they decide to do so, so there is hope.

Next steps

I think I'll work on a prototype that allows bckt¹¹ to implement these features, and get a first-hand experience on what needs to be built and how.