Relay

A server that stores and forwards events. In Gozzip, relays also perform oracle duties — resolving device subkeys to root identities transparently for clients. In the storage pact model, relays are optional accelerators — users' storage peers can serve data independently.

In the persona model, relay operators are Heralds — town criers who curate and relay content for beyond-graph reach. See Glossary.

Responsibilities

  • Store events published by clients
  • Serve events matching subscription filters
  • Cache kind 10050 (device delegation) events
  • Resolve device → root identity on subscriptions: when a client subscribes to a root pubkey, the relay fetches the delegation list and returns events from all authorized device pubkeys as a unified feed
  • Index events by root_identity tag for fast lookups

Oracle Resolution

When a client subscribes to root_pubkey:

  1. Fetch kind 10050 → get authorized device pubkeys
  2. Fetch kind 1, 30023, etc. where pubkey IN [device_pubkeys]
  3. Return as unified feed attributed to root identity

Light node (Witness) shortcut: Fetch kind 10051 (checkpoint) → get device heads → fetch only events after head per device.

Relay Types

Not all relays serve the same purpose. Different types provide different value to the network.

All three relay types below are Herald variants — they differ in curation strategy but share the Herald role of extending reach beyond the social graph.

Discovery relays — curate content by topic, quality, or community. They index selectively, surfacing posts they think are valuable. Users follow a discovery relay's feed like they follow a person. The relay's value is taste — it earns followers by being a good filter.

Infrastructure relays — store broadly, serve fast, high availability. Their value is performance and reliability. They remain useful as accelerators even when users have 15+ storage pacts (sovereign phase).

Community relays — serve specific groups (NIP-29 group chats, local communities, interest groups). Their value is exclusivity and curation within a community. Membership in the community is the incentive to use the relay.

Relay-as-Curator

A relay has its own root pubkey. It publishes curated event lists, recommendations, or indexes. Users who find value subscribe (follow the relay). The relay's follower count and WoT position determine how far its curations travel through gossip. See ADR 009.

  • Good curation → more followers → wider reach → more users want to publish through the relay
  • Publishing through a well-connected relay makes your content visible to that relay's subscribers — an audience beyond your own WoT
  • The relay becomes a distribution channel — users who contribute good content to the relay's community are more likely to be curated

Lightning Services

Relays can offer premium services activated via zaps (kind 9734/9735). This is the optional Lightning layer on top of the free attention economy. See ADR 009.

Service What you get How it works
Priority delivery Faster indexing, wider push to relay subscribers Zap relay per-event or per-month
Extended retention Events kept beyond default window Zap relay for duration (e.g., 100 sats/month for 1-year retention)
Content boost Specific post featured in relay's curated feed Zap relay with tagged zap pointing to the event. Marked as boosted (transparent).
Onion routing Gossip requests wrapped in NIP-44 encrypted layers per hop — hides request path from intermediate nodes Zap relay for onion routing access. Primarily useful for desktop/web clients.
Relay-defined services Whatever the operator invents Analytics, custom filtering, API access, webhooks — relays compete on features

Properties:

  • Transparent — boosted content is visibly marked. No dark patterns.
  • Competitive — different relays offer different prices and services. Market dynamics, not protocol-mandated pricing.
  • Optional — the free attention layer works without any Lightning.
  • Accountability — relays that take sats but deliver poorly lose subscribers to competitors.

Interactions

  • User/Client — accepts published events, serves subscription feeds
  • Other relays — may replicate events (relay-to-relay sync)
  • WoT oracle — generates and indexes checkpoints for light node sync
  • Bridge — forwards events to/from other networks

Resolved Questions

  • What are the incentives for running a relay? — Ecosystem-native value through the three-layer incentive model. Free layer: relay-as-curator earns followers → influence → users publish through it. Lightning layer: priority delivery, extended retention, content boost, and relay-defined services paid via zaps. Different relay types (discovery, infrastructure, community) monetize their unique value differently. No external subscriptions needed — though operators can still charge if they want. See ADR 009.
  • How much oracle logic belongs in the relay vs in a separate service? — Oracle resolution (device → root) lives in the relay. It's a kind 10050 lookup and an index by root_identity tag — lightweight enough to be a query optimization, not a separate service.
  • Relay retention policies — how long are events kept? — Relay-defined. Since storage peers hold canonical data, relays can set aggressive retention (e.g., 30 days) without risk of data loss. Always-on relays may keep longer for discoverability. No protocol-level retention requirement.
  • Should relays validate root_identity tags against kind 10050, or trust clients? — Validate. Relays verify the root_identity tag against kind 10050 before indexing. This prevents impersonation where a rogue client claims a root_identity it's not authorized to use. Cost is one 10050 lookup per new device pubkey, cached after first verification.