Document type: Protocol overview. NIP-01 describes Nostr’s basic protocol flow, while other NIPs describe possible extensions. The project’s protocol repository points readers to the NIPs rather than identifying a separate formal whitepaper as the primary specification.
This guide explains Nostr’s keys, events, and relays, along with important limits. It is educational material, not investment advice or a guarantee of privacy or service availability.
What is Nostr?
Nostr is an open protocol for publishing and retrieving messages through clients and relays. Its name stands for “Notes and Other Stuff Transmitted by Relays.” Nostr is not a blockchain and does not define a native token. Different parties can operate clients and relays, and each relay can set its own policies.
Keys and events
In the basic flow, an account does not depend on a username issued by one central server. A user creates a key pair: the public key serves as a cryptographic identifier, while the private key signs events. NIP-01 defines the event format, including the public key, creation time, event kind, tags, content, ID, and signature.
Clients can check a signature to confirm that an event was created by the holder of the corresponding key and was not changed after signing. A signature does not hide the event’s contents. Public events can still be read by relays that store them and by clients that retrieve them.
What relays do
A relay is a server that receives, stores, and serves events. NIP-01 describes the basic client-to-relay messages: EVENT to publish an event, REQ to request or subscribe to events, and CLOSE to end a subscription. A client can publish to more than one relay, but NIP-01 does not guarantee that all relays store, forward, or display the same content.
Relays may reject or remove events under their own policies. Using several relays can reduce reliance on a single operator, but finding users and content still depends on the relays a client uses and how it combines their results. A relay can also observe connections and public events it handles; signatures alone do not provide anonymity.
NIPs and optional features
NIP stands for “Nostr Implementation Possibilities.” The NIP repository describes possible features for compatible clients and relays; applications do not have to support every NIP. As a result, Nostr capabilities can differ from one client to another.
- NIP-05: An optional mapping between a public key and a domain-based identifier, such as name@example.com. Its specification describes this as identification, not verification of a person.
- NIP-57: A draft, optional design for “Lightning Zaps,” connecting Nostr events with a Lightning payment flow. Using it requires support from the client and receiving service.
Limits to understand
Nostr does not automatically make all content censorship-resistant, private, or permanently available. Relays can reject events, users may lose access if the relays they rely on stop storing data, and profile discovery can be limited. Users are also responsible for protecting their private keys. An open protocol allows many clients and relays, but the experience depends on the choices and practices of their operators.
Social Media Sentiment
In a small sample of community discussions reviewed, supporters valued being able to choose or change relays instead of depending on one platform. Other commenters questioned relay operating costs and whether content discovery could concentrate around a few large relays. Discussions of relay-to-relay synchronization saw potential to improve discovery, alongside concerns about bandwidth, spam, and moderation. These posts are anecdotes, not a representative measure of all users. See the discussion of relay roles and operating economics and federated relay synchronization.
Last updated: 2026-10
Related Terms
See Also
Sources
- Nostr Protocol README — introduces the protocol, clients, relays, and signed events, and points readers to the NIPs for protocol details.
- NIP-01: Basic protocol flow description — specifies the basic event format and client-to-relay messages.
- Nostr Implementation Possibilities repository — explains the scope of NIPs and that apps choose which features to support.
- NIP-05: Mapping Nostr keys to DNS-based internet identifiers — defines the domain-based identifier mapping and its limits.
- NIP-57: Lightning Zaps — describes the optional, draft flow connecting events to Lightning invoices.
Updates
Updated October 14, 2026.