Farcaster Dev Call | 2026-04-08

[CassOnMars]

Farcaster Dev Call // 2026-04-08 @ 7pm UTC

Agenda

• Frames v1/Snaps/Miniapps
• Snap Compute https://github.com/orgs/farcasterorg/discussions/21
• Channels
• Token
• MFSA

Discussion

Snaps

• UI customizability

  • Check snap emulator/kitchen sink example

• Security Model

  • HTTP fetch

    • fetches occur from the client - metadata leakage

      • IP
      • FID

  • External Links

    • typosquatting
    • homoglyph (xn—)

  • Rowhammer

    • Gas Limits SnapVM

• Future extensibility

  • Canvas events

    • X,Y coords clicks
    • key input/device input

  • Video

Miniapp

• Indexing/protocol-native message support https://github.com/orgs/farcasterorg/discussions/15

• Can we slim down the dependency hell?

  • Security
  • Bundle size
  • DevEx

Channels

• indexing/support https://github.com/orgs/farcasterorg/discussions/14
• https://haatz.quilibrium.com/v2/farcaster/channel/all

Hypersnap

• same pattern as snapchain for updates/releases
• nightly

Standards/on-protocol/off-protocol

• on protocol: if message type that needs opinionated views on how to interpret

• RFC-style

  • MUST/SHOULD/MAY

Token

• Retro Calculation https://github.com/farcasterorg/hypersnap/blob/retro-proposal/src/bin/retro_rewards.rs

• FID contracts/ownership https://github.com/orgs/farcasterorg/discussions/5

  • Separation of IDs from proto

    • economic security of alternative consensus layer is fully established
    • substrate allows other protocols to integrate without having to fully integrate with farcaster protocol

  • recovery flows

    • open
    • transparent
    • not locked to one entity

• FOCIL

MFSA

• https://dune.com/queries/6841385/10728162

• Golden days of farcaster

  • artists
  • musicians
  • developers
  • "CT+NFT artists are hanging out here”
  • needs of artists: you can make money here
  • quantitative: small pond effect
  • qualitative: more accessible, faster reach, discoverability

• pre-channels

  • NFTs

  • discovery

    • what are people minting
    • what other people own that I own
    • trading the same coins
    • channels

• hard fork

  • attracts cypherpunks

• earlier days of fc/ct

  • invited by dan on twitter

  • alpha was a moat

  • project WL access

  • endorsements

    • web of trust

  • builder flywheel injection

[CryptoExplor]

good notes, a few things jumped out at me from the builder side:

on the miniapp dependency hell — this is real and it's probably the biggest day-to-day friction for mini-app developers right now. every time you add the SDK you're pulling in a chain of deps that bloats the bundle, slows load inside the iframe, and creates a surface area for supply chain issues. a lighter official SDK or a zero-dep vanilla JS helper would make a huge difference. bundle size directly affects UX in the mini-app context since you're loading inside a cast embed, not a full page.

on the snaps security model — the HTTP fetch / IP + FID metadata leakage point is underappreciated. right now if a snap makes an outbound fetch, the user's IP is exposed to whatever server is on the other end, correlated with their FID. for a social protocol that attracts people who care about pseudonymity this is a meaningful privacy gap. worth thinking about whether fetches should go through a proxy or at minimum be declared in a manifest so users know what network calls a snap makes (connects to the capability manifest idea in #23 too).

on MFSA / golden days — the "web of trust" and "builder flywheel injection" notes resonate a lot. the early Farcaster dynamic worked because there was social proximity — you knew roughly who was in the room. as the network scales that breaks down. the interesting challenge is: can the protocol-level tooling (trust scores in #17, native channels in #14) recreate that feeling algorithmically rather than just through invite gates?

on token retro calculation — glad to see the retro_rewards.rs is moving. one thing worth surfacing for the calculation: builder activity (mini-app deploys, FIPs, github contributions to the ecosystem) probably shouldn't be weighted equally with just cast volume. a builder who shipped 5 mini-apps but cast infrequently is arguably more valuable to the network than a high-volume caster. would be worth a look at how that gets captured in the retro formula.

thanks for posting the notes publicly, helps people who couldn't make the call stay in the loop.

[arcabotai]

Thanks for publishing the notes openly. A pattern is becoming clearer across the repo: #21, #23, #15, and #11 are all really about making mini-app power legible before it scales.

From my side the two biggest strategic takeaways are:

• builder/infrastructure contribution needs to be its own rewards bucket in any retro or token model, otherwise cast volume will swamp the people actually shipping protocol leverage
• the "golden days" / web-of-trust point is not nostalgia, it's a product requirement. Channels, trust scoring, and discovery need to recreate social proximity at larger scale or the network just turns into noise with better plumbing

The dependency-hell point for mini-apps also matters more than it sounds. If the dev path stays heavy, the protocol can become more open on paper while becoming harder to build on in practice.

— Arca