nexus-go — Quick guide

nexus-go is the Go runtime behind the Nexus bridge stack — Blurt's social layer. It indexes the chain into PostgreSQL and serves everything a social front-end needs (feeds, communities, profiles, follows, notifications, search, drafts, and media) through a JSON-RPC API, so the browser never has to assemble those views from raw chain calls.

Consensus vs. the social layer

blurtd is the source of chain truth; nexus-go is the derived social view of it. Anything nexus-go serves can be rebuilt from the chain — it never holds authority over funds or consensus. Writes (posting, voting, transfers) still go to the chain, not to nexus-go.

Where it sits

  blurtd  ──►  nexus-go-indexer  ──►  PostgreSQL  ──►  nexus-go-api  ──►  front-ends
 (source)      (+ materializer,       (nexus_*        (bridge.* +        (condenser,
                 + enrich)             tables)         social reads)      forums, apps)

Front-ends never talk to nexus-go directly: they reach it through the RPC proxy, which routes the social methods (bridge.* and the social subset of condenser_api.*) to nexus-go-api, and everything consensus to the node. One RPC URL, one call routed to one backend.

The four services

• nexus-go-api — the JSON-RPC / bridge API service. Read-only over the store for social data; it never signs or broadcasts.
• nexus-go-indexer — the chain indexer and sync worker. Tails blurtd and writes normalized social state into the nexus_* tables.
• nexus-go-materializer — a derived-view worker that precomputes expensive UI/API views (trending tags, account blogs, …) so hot paths stay fast.
• nexus-enrich — a post-sync job that advances and validates derived datasets after a restore or catch-up.

Two indexers, don't confuse them

nexus-go has its own internal indexer (the indexer + materializer above) that builds feeds and communities. It is separate from the standalone wallet indexer, which answers wallet_history.*. See Architecture for the whole picture.

What it serves

• Feeds — ranked, account, and forum/community timelines.
• Communities — listing, roles, subscribers, subscriptions, and moderation.
• Profiles & social graph — profiles, followers/following, follow counts.
• Notifications — account and post notifications, unread counts.
• Search — posts, comments, accounts, and tags.
• Drafts & media — server-side drafts and the media upload/serve flow.
• Witnesses & analytics — witness data plus trending, engagement, and reward analytics.

It also answers the social subset of condenser_api.* (discussions, content, blog, follows), so the classic condenser API is backed by the same store.

Run it

nexus-go runs as a Compose stack (API + indexer + materializer, backed by PostgreSQL) that indexes from a reachable blurtd. Because a full historical index is large, real deployments start from a published data baseline and then sync forward and enrich, rather than indexing from genesis.

The end-to-end deployment flow (baseline restore, sync, enrichment, and validation) is operator-specific and lives in the repository. See the Reference for the architecture and API surface, and the repository for deployment.

Next

• Reference — the service architecture, the indexer/materializer model, communities and moderation, and the full bridge.* API surface.
• Source: blurt/nexus-go.