Docs
Building on Buzzer

Indexer

Because almost everything on Buzzer is an event — posts, reactions, community activity, messages, media — building an indexer is mostly just collecting event logs and organising them. There is no special node software and no separate data network to run: you read logs from an ordinary EVM RPC endpoint.

Why it's easy to build your own

The contract deliberately keeps very little in state (identity, profile data, graphs) and emits everything else. That means the full history of the network is reconstructable from the log stream alone:

  • Posts — every buzz is a Buzzed event with the author uid, bid, parent, type, content and settings. There is no on-chain post storage to query; you build the feed by indexing Buzzed and applying BuzzDeleted (ignoring deletes whose uid doesn't match the original author).
  • Reactions & tips — Reacted carries the target, reaction type, and tip details; verify tip amounts against the token's own Transfer logs.
  • Communities — CommunityCreated, CommunityPosted, CommunityStandingSet and friends give you membership, roles and community feeds.
  • Media — Media events, grouped by hash, resolve files across storage locations.
  • Identity & graph — read from contract storage (or the BuzzerLens aggregator) for the authoritative current state, and use events for history.

Each client interprets it its own way

The contract records but does not interpret post types, relationship bits, reaction types, or community standing. An indexer applies the convention layer to give those raw records meaning — and different clients can legitimately interpret the same events differently (which relationship bits to surface, which post types to render, how to filter a community). The chain is the shared source of truth; the interpretation is yours.

Light clients

For narrow needs you may not need a full indexer at all. Because the key ids are indexed in the events, a light client can filter directly — an inbox is Message events where to == myUid, a profile's media is Media events where uid == theirUid, and so on.

More docs coming soon — a reference indexer schema and a hosted read API are in progress. For now, the event definitions in the contract API are the complete specification an indexer needs.