Nostr Relay

A Nostr Relay is a simple, stateless server that receives, stores, and broadcasts messages, called events, for users of the decentralized Nostr protocol. Unlike servers in centralized platforms, relays do not authenticate users, control identities, or enforce a global state; they are dumb pipes that accept valid events from anyone and make them available to subscribers. Users run a Nostr client (like an app) that connects to multiple relays of their choosing to publish notes and receive updates from others, creating a resilient and censorship-resistant network where no single entity has control.

The architecture is intentionally minimalistic. Relays communicate with clients via a standardized WebSocket or HTTP-based protocol, exchanging JSON-formatted events. Each event is cryptographically signed by a user's private key, allowing anyone to verify its authenticity and origin. Key functions of a relay include: - Validating event signatures and structure - Storing events temporarily or permanently - Allowing clients to query for events using filters (e.g., by author, time, or content) - Forwarding events to other connected clients in real-time. This design enables users to maintain their social graph and data across a diffuse network of independent servers.

Running a relay is a public service, similar to running a Bitcoin node, but it can also be a private or paid service. Public relays foster network liquidity, while private relays allow individuals or communities to control their data flow and ensure availability. Since there is no inherent economic incentive, relay operation is often altruistic or supported by donations. The decentralized nature means if one relay goes offline or censors a user, the client can simply connect to others, ensuring data redundancy and anti-fragility. This makes Nostr fundamentally different from federated protocols like ActivityPub (used by Mastodon), which rely on inter-dependent servers.

For developers and users, the relay model offers significant flexibility. A client can aggregate data from dozens of relays to get a complete view, or use specialized relays for specific content types (e.g., one for global chat, another for long-form articles). The protocol's simplicity has led to a vibrant ecosystem of implementations in various programming languages, making it easy to deploy a custom relay. The ultimate power resides with the user, who controls their private keys, chooses their relays, and owns their social data—a core tenet of the "self-sovereign" social web that Nostr enables.

A Nostr relay is a simple, stateless server that receives, temporarily stores, and broadcasts events—the fundamental data units in the Nostr protocol—between clients. Unlike servers in federated or blockchain-based systems, relays are intentionally minimal and interchangeable; they perform no authentication, impose no global rules (unless operated privately), and do not communicate with each other. A client's resilience and access to the network depend on its connection to multiple, independent relays, creating a redundant and censorship-resistant mesh. The primary interaction is via a WebSocket connection, where clients send EVENT and REQ messages to publish and subscribe to data.

The relay's core function is event validation and storage. Upon receiving an event—which is a signed JSON object containing content, metadata, and a cryptographic signature—the relay performs basic checks. These typically verify the event's id (a SHA256 hash of its contents), the validity of the cryptographic sig against the author's public key, and adherence to the Nostr protocol specification (NIPs). Optionally, a relay operator may enforce additional rules, such as rate-limiting, content filtering, or requiring payment (as defined in NIP-05 or NIP-65). Valid events are stored in the relay's local database and immediately broadcast to all connected clients subscribed to relevant filters.

Client interaction is governed by subscription filters. A client opens a subscription by sending a REQ message with an array of filter objects (e.g., {"authors": ["pubkey..."], "kinds": [1]}) to request text notes from specific users. The relay then returns all matching historical events from its database and pushes new, matching events in real-time. This publish-subscribe model is highly efficient, as a single client connection can manage dozens of active subscriptions. Since relays are independent, a client must connect to several to gather a complete view of the network, a design that prevents any single point of failure or control.

Operationally, relays can be public, private, or paid. A public relay accepts connections and events from anyone, often becoming a large, general-purpose hub. A private relay may restrict access to a specific community or set of public keys, acting as a gated server. Paid relays, enabled by mechanisms like NIP-05 (Lightning payments), require a small fee to publish or read, which helps mitigate spam and funds infrastructure. The relay software itself is typically open-source, with implementations like nostr-rs-relay (Rust) or strfry (C++) providing the core functionality for operators to deploy.

The decentralized architecture means data persistence is not guaranteed. A relay operator can choose to delete old events, go offline, or purge data at any time. Therefore, Nostr clients and users are responsible for their own data durability by publishing events to multiple relays and using personal Nostr clients that archive their own data. This model shifts the burden of permanence from the network infrastructure to the edges, aligning with Nostr's philosophy of minimal trust. The relay's role is purely one of voluntary, temporary hosting and real-time message passing within a global, permissionless ecosystem.

In the Nostr (Notes and Other Stuff Transmitted by Relays) protocol, the client-relay relationship is a simple, stateless, and permissionless connection model. A client (any software that creates or requests data, like a social media app or a wallet) connects to one or more independent relays (servers that store and forward messages). This relationship is not exclusive; a single client typically connects to multiple relays for redundancy and data access, while a single relay serves countless clients. The core operations are publishing events (e.g., posts, reactions) to relays and subscribing to filters to receive relevant events from them.

This architecture creates a decentralized and censorship-resistant network. There is no central server or mandatory relay. If one relay rejects a user's content or goes offline, the client can simply connect to others. The relationship is standardized through open protocols—primarily using WebSockets—where clients send EVENT and REQ messages, and relays respond with EVENT, EOSE, and NOTICE messages. This ensures interoperability between any compliant client and relay software, such as nostr-rs-relay or Damus.

The economic and operational model of this relationship is flexible. Relay operators may choose to run public relays freely, private relays for specific communities, or paid relays that require authentication (NIP-42) or payment (e.g., via NIP-57 Lightning zaps) for service. Clients must strategically manage their relay connections, balancing factors like latency, reliability, cost, and the specific data filtering each relay supports (NIP-01). This design places control with the user's client software, which is responsible for aggregating the user's social graph and content from the disparate relay network.