Hypersnap Meeting 2026/01/06

Topics

Identify core deficiencies in snapchain that can be improved to better serve clients

Improve miniapp experience for users and builders alike, grow to do more than just speculative/reward-grinding apps

Improve protocol integration experience

Identify protocol enhancements that would grow quality usage on Farcaster

Explore network token

Create the path for complementary building of protocol features without forking

Discussion

• Foster a shift in culture from gambling/speculation to long-form / high-quality content

  • Idea space: on-chain channels as an enabling primitive (potentially DAOs), but the effort stalled early.
  • “Hypersnap” is a complementary network protocol that could help surface better content and/or enable alternative feeds.

• Make Farcaster clients meaningfully easier to build

  • Snapchain feels close to “easy client territory,” but there are missing basics.
  • Concrete ask: client-building should be simpler, example: “simple message scheduling” as a first-class capability.

• Data & analytics need a real “query layer,” not bespoke indexers

  • Current state: had to build a custom Neynar indexer to do custom queries.
  • Desire: a first-party or standard way to run custom queries over Snapchain’s rich graph (threads/casts/reactions), potentially via GraphQL.

• Feed construction is currently ad-hoc and too SQL/client-specific

  • Example: feeds built from custom SQL (e.g., long-cast feed at 1500+ chars).
  • Observation: feed logic is “flattened” across existing APIs.
  • Direction: support configurable/custom query behaviors; prioritize existing approaches (spam filtered, popularity ordered, nested) as a benchmark.

• Token design: incentives vs coordination-without-token

  • If there’s a token: it should reward securing the network, building clients/mini-apps, and producing quality content.
  • Concern: money distorts behavior; question whether Hypersnap could coordinate curation/behavior without a token (AT Proto mentioned as an example counterpoint).

• Curation layer as a primitive

  • Curation is seen as a missing layer: could be manual curation primitives and/or miniapp-based curation mechanisms.

• DevEx (developer experience)

  • DevEx is called out as a core problem area (details elaborated later under docs/AI-first builders).

• Distribution of value

  • Fundamental monetization question: what would users consider valuable enough to actually pay for?

• “Template client”

  • Suggestion: provide a reference/template client to lower the floor for client builders and standardize best practices.

• Docs are bad for “AI-first / vibe-coding” developers

  • The docs should optimize for minimal steps / minimal lines to get a client or miniapp working.
  • Goal: make it dramatically easier for miniapp builders to start.

• Creator/artist retention

  • Pain point: “we lost a lot of artists.”
  • Hypothesis: feeds focusing on media didn’t translate into retaining that creator cohort (or didn’t support them in the right way).

• Help specific communities grow via curation

  • Problem: emerging communities need attention routing.
  • Proposed lever: curation mechanisms that can spotlight and bootstrap specific sub-communities.

• Clearer, more direct path to build mini apps

  • Desire for an obvious “on-ramp” (mini app studio / Neynar-like tooling mentioned) so building is straightforward.

• Make “How can we help?” actionable via surfaced CTAs

  • Product idea: explicitly surface calls-to-action for the ecosystem:

    • build on protocol, build clients, build miniapps, curate.

Highest Leverage Actions

Ship a real “Query Layer” (stop forcing custom indexers)

• Goal: let anyone run custom queries over casts/threads/reactions

• Deliverables:

  • A canonical indexed dataset + public query endpoint (start with read-only). Done: Initial draft of hypersnap hypersnap#1
  • GraphQL (or equivalent) with a small set of “blessed” primitives: threads, reactions, channel/community filters, time windows.
  • Examples for common use-cases: “long-form feed”, “community feed”, “mutuals+replies”, “anti-spam ranking”.

• Justification: unlock feeds and analytics

Make client-building a “template + SDK” experience

• Goal: “I can build a client in a weekend.”

• Deliverables:

  • Template client: (web + mobile optional) wired to auth, reading, posting, reactions, threads.
  • Minimal SDK: with opinionated defaults (pagination, caching, rate limits, retry).
  • A “recipes” folder: build a feed, build a channel view, build notifications, etc.

• Success criteria: “clone → deploy → working client” in <30 minutes, <100 lines of code.

Turn channels and curation into first-class primitives (manual + miniapp-driven)

• Goal: create non-gambling paths to discovery and community growth.

• Deliverables:

  • Curator primitive: curated feed spec
  • Channel primitive
  • Miniapp curation hooks: apps can define curation logic and publish “channels/feeds”.

• Success criteria: “quality content” + “help communities grow.”

Miniapp On-Ramp + Distribution

• Goal: make miniapps easy to build and easy to get users.

• Deliverables:

  • Scaffolding/Starter Kits: generator + templates (auth, query calls, UI shell, deploy target).
  • Miniapp primitive: canonical listing to surface in clients.
  • Trust & permissions: more granular capability model (“this app can read X, post Y”), lightweight review/attestation, abuse throttles.
  • Open analytics loop: installs, retention, conversions so builders can iterate and users can trust what they’re installing.

• Success criteria: more quality mini apps

Native monetization + value distribution primitives

• Goal: make it straightforward for creators/curators/miniapps to earn in ways that reinforce quality (and help retain artists), answering “what would people pay for?”

• Deliverables:

  • Paid access/subscription primitives: subscriptions/memberships to a creator, community, or curated feed (with free preview tiers).
  • One-off payments primitives: tips, “unlock this post/thread,” paid bookmarks/collections.
  • Revenue sharing rails: configurable splits for collabs (creator + curator + miniapp), with transparent (but private) receipts.
  • Portable entitlements: membership recognized across clients/miniapps (not siloed per app).

• Success criteria: get creators paid, first time creator getting their first $100, then $1,000, then $10,000, etc.

How can I help?

• Developers:

  • Contribute to Hypersnap – each of the primitives above needs to be specced out, and built.

  • Contribute to Quorum Mobile – protocol integration is a two way street, clients need to support the primitives added.

  • Build on both:

    • miniapps
    • clients
    • integrations
    • ai agents
    • other tools

• Creators/Artists:

  • Sanity check us! Do these proposals make sense to you? Are there alternatives that can work better?
  • Be a pioneer – join in our experiments of these proposals, tell us what works, what doesn’t

• Product Managers:

  • Go away.