Architecture

The stack is layered: the blockchain as the source of truth at the bottom, a node that serves it, backend services derived from it, a single RPC endpoint in front, and the front-ends on top.

Two indexers, don't confuse them

The wallet-indexer is the standalone service that answers wallet_history.* (account history). nexus-go has its own internal indexer that builds feeds and communities — it lives inside nexus-go, not as a separate component, and is documented under nexus-go.

The layers

1. Source of truth — the Blurt blockchain: the decentralized ledger. No single machine is the chain; the network is.
2. Node — blurtd: a consensus node that validates the chain and serves it over JSON-RPC. Everything above reaches the chain through a blurtd node.
3. Backend services — read the chain (through blurtd) and serve derived data:
   • nexus-go — feeds, threads and communities (the bridge API).
   • wallet-indexer — fast account / wallet history.
4. RPC proxy — one JSON-RPC endpoint, routing each call by method prefix: condenser_api.* → blurtd, bridge.* → nexus-go, wallet_history.* → wallet-indexer.
5. Front-ends — condenser (web) and the wallet — call that one endpoint and render the result.

How a read flows

1. A front-end calls the RPC proxy — the same endpoint it uses for everything.
2. The proxy routes each call by method prefix to a blurtd node, nexus-go or the wallet-indexer.
3. That backend answers — from the chain (via blurtd) or from its own index — and the front-end renders the result. One endpoint, so a front-end needs no special configuration per service.

How a write flows

Posting, transferring, or voting is a signed transaction broadcast to a blurtd node, which propagates it to the network. Once it lands in an irreversible block the backend services pick it up: nexus-go threads it into feeds and communities (through its own internal indexer), the wallet-indexer records the wallet-relevant parts, and the front-ends show it.