• The Fundamental Unit of the Network
• NIP-01: The Basic Contract
• NIP-11: Announcing What You Are
• What Relays Store: Retention and Expiration
• What Relays Forward: Subscriptions and Filters
• What Relays Block: Authentication, Payment, and Policy
• NIP-65: Telling the World Where You Are
• NIP-66: Finding Relays Themselves
• Specialized Relays: The Long Tail of NIPs
• The Relay’s Perspective: What Implementation Looks Like
• The User’s Perspective: Choosing Jurisdictions
• The Network Effect of Sovereignty
• The NIPs as Constitutional Documents
• Choosing Wisely
• References

§The Fundamental Unit of the Network

A Nostr relay is not complicated. It is a server that accepts connections from clients, receives events from them, stores those events (or not), and forwards them to other clients who request them. That is the entire description. Everything else is policy.

This simplicity is the source of the network’s power. Because relays are simple, they can be run by anyone. Because they are independent, they can have any rules. Because they are numerous, no single relay controls the network. The relay is the unit of sovereignty in Nostr. Each one is a territory, governed by its operator, populated by its users.

Understanding what relays do—what they store, what they forward, what they block—is understanding how the network actually functions. And the specifications that define these possibilities are found in the NIPs.

§NIP-01: The Basic Contract

Every relay implements NIP-01. It is the foundation, the minimal set of behaviors that makes a server a Nostr relay.

NIP-01 defines the message types that clients and relays exchange. When a client wants to publish an event, it sends an EVENT message. When it wants to receive events, it sends a REQ message with filters. When it wants to stop receiving, it sends a CLOSE message.

The relay responds with EVENT messages (sending events that match subscriptions), EOSE (end of stored events), OK (confirming receipt of an event), CLOSED (ending a subscription), and NOTICE (human-readable messages).

These message types are the language of relay-client communication. They are all that is strictly required. Everything beyond them is optional, a possibility that a relay may choose to implement.

But within these simple messages lies enormous flexibility. The relay decides which EVENT messages to accept. It decides which events to store. It decides which subscriptions to honor. The protocol defines the language, but the relay defines the policy.

§NIP-11: Announcing What You Are

Before a client connects to a relay, it might want to know what kind of relay it is dealing with. NIP-11 provides a way for relays to publish information about themselves.

A relay that implements NIP-11 responds to HTTP requests to its domain with a JSON document containing metadata. This document can include:

• The relay’s name and description
• The software it is running
• Contact information for the operator
• Supported NIPs
• Limitations on event size, number of subscriptions, etc.
• Retention policies
• Fee requirements

This information allows clients to make informed choices about which relays to use. If a relay deletes events after a week, you might not want to use it for archival content. If a relay requires payment, you might choose a free alternative. If a relay supports certain NIPs, you might prioritize it for specific features.

NIP-11 turns relay selection from a blind guess into an informed decision. It is the relay announcing its sovereignty, stating its rules for all to see.

§What Relays Store: Retention and Expiration

A relay’s most fundamental decision is what to store. Some relays store everything forever. Some store nothing, acting as ephemeral pass-throughs. Most are somewhere in between.

NIP-11 can announce retention policies, but the actual storage behavior is implemented by the relay software. Different relay implementations make different choices.

Some relays are specialized. A relay focused on NIP-23 long-form content might store only kind 30023 events. A relay for NIP-15 marketplaces might store only marketplace events. A relay for NIP-71 videos might store only video events. The kind system, defined across many NIPs, allows relays to specialize by event type.

NIP-40 gives users some control over retention. Events can include an expiration tag with a timestamp. Relays that respect this tag will delete the event after that time. This is useful for time-sensitive content, temporary announcements, or anything that should not persist indefinitely.

NIP-09 allows users to request event deletion. A kind 5 event, if accepted by a relay, indicates that the original event should be deleted. Relays may honor this request or ignore it. The choice is theirs.

Storage is not guaranteed. It is a service that relays provide according to their own policies. Users who want permanent storage must choose relays that offer it, or run their own.

§What Relays Forward: Subscriptions and Filters

Forwarding is what relays do when clients request events. A client sends a REQ message with filters, and the relay sends back matching events.

The filters can be quite sophisticated. They can specify authors, kinds, tags, date ranges, and more. NIP-01 defines the basic filter structure. Other NIPs add additional filtering capabilities.

NIP-50 adds search functionality. Relays that implement it can accept search filters, returning events that match text queries. This is computationally expensive, so relays may limit or charge for search.

NIP-45 allows clients to request counts of events matching filters, without retrieving the events themselves. This is useful for analytics, for showing “X people liked this,” or for deciding whether to request the full events.

NIP-77 describes negentropy syncing, an efficient protocol for synchronizing event sets between relays and clients. This is useful for backups, for mirroring, for any situation where two parties need to agree on what events they have.

When a relay forwards events, it is acting as a distribution hub. It takes events from publishers and delivers them to subscribers. But it only forwards what it has stored, and it only forwards to clients whose subscriptions it chooses to honor.

§What Relays Block: Authentication, Payment, and Policy

A relay’s power to block is as important as its power to store and forward. Every relay can refuse any event, any subscription, any client, for any reason.

NIP-42 provides a mechanism for authentication. A relay can send an AUTH challenge to a client, requiring it to authenticate before performing certain actions. The client responds with an authenticated event (kind 22242) proving control of a key. This allows relays to restrict posting to known users, to implement rate limits per identity, or to create private spaces.

Authentication does not mean the relay learns your key. It just means you prove you control a key. The relay can then make decisions based on that identity.

NIP-43 describes relay access metadata and requests, providing additional mechanisms for access control. NIP-86 defines a relay management API for operators to configure their relays.

Blocking can also be economic. NIP-13 allows events to include proof-of-work, a computational effort that makes spam expensive. Relays can require a minimum difficulty for acceptance, ensuring that only those willing to invest computation can post.

Relays can block based on content. NIP-56 provides a reporting mechanism, allowing users to flag events for review. NIP-36 allows events to be marked as sensitive, with clients choosing whether to display them. But the final decision to block is always the relay’s.

The beauty of this system is that blocking is always local. A relay that blocks you does not silence you. It just means you stop using that relay. Your words survive on other relays that have different policies.

§NIP-65: Telling the World Where You Are

If relays are sovereign territories, users need a way to announce which territories they inhabit. NIP-65 provides this through kind 10002 events, which list a user’s relays.

A kind 10002 event contains a list of relays, each with an optional marker indicating whether it is for reading, writing, or both. This is the user’s declaration: “I post my content to these relays. I read replies from these relays.”

When a client wants to find your content, it looks up your kind 10002 event and queries the relays you listed. When someone wants to reply to you, they look up your kind 10002 and post to your read relays.

This is the outbox model in action. It works because relays are independent but users can coordinate by publishing their relay choices. The protocol does not mandate this coordination. It enables it.

NIP-65 also allows relays to be listed without markers, simply as places where the user can be found. The flexibility accommodates different use cases while maintaining a simple core.

§NIP-66: Finding Relays Themselves

With thousands of independent relays, how do users find them in the first place? NIP-66 provides a solution through relay discovery and liveness monitoring.

A kind 10166 event announces a relay monitor—a service that tracks relay status. These monitors can publish lists of relays, their uptime, their supported NIPs, and other metadata. Clients can use this information to discover new relays and to choose reliable ones.

Relay discovery is itself decentralized. Anyone can run a monitor. Anyone can publish relay lists. The network has no single source of truth for relay information, just as it has no single source of truth for content.

This is the pattern that repeats throughout Nostr: problems are solved not by centralizing, but by distributing the solution. Anyone can contribute. Anyone can verify. The network grows stronger as more participants join.

§Specialized Relays: The Long Tail of NIPs

The list of NIPs reveals the incredible diversity of possible relay specializations. Each NIP that defines a new event kind creates an opportunity for relays that specialize in that kind.

NIP-15 defines marketplace events. A relay could specialize in these, becoming a hub for Nostr commerce. NIP-23 defines long-form content. A relay could focus on articles and essays. NIP-28 defines public chat. A relay could become a chat server. NIP-29 defines relay-based groups. A relay could host communities. NIP-35 defines torrents. A relay could become a torrent index. NIP-52 defines calendar events. A relay could become an event listing service. NIP-53 defines live activities. A relay could stream live content. NIP-54 defines wiki articles. A relay could host a wiki. NIP-68 defines picture-first feeds. A relay could become an image gallery. NIP-71 defines video events. A relay could become a video platform. NIP-72 defines moderated communities. A relay could host forums. NIP-88 defines polls. A relay could conduct surveys. NIP-99 defines classified listings. A relay could become a classifieds site. NIP-A0 defines voice messages. A relay could host audio content. NIP-C0 defines code snippets. A relay could become a code sharing platform.

Each of these is a possibility, not a requirement. Relays can choose which kinds to accept, which to store, which to forward. They can specialize narrowly or remain general. The protocol accommodates all approaches.

§The Relay’s Perspective: What Implementation Looks Like

Consider what a relay operator actually does. They choose software—perhaps strfry for a lightweight C++ implementation, or nostream for a feature-rich TypeScript relay, or something else entirely. They configure it with their policies. They point it at a domain. They open port 443. They are now a sovereign territory in the Nostr network.

Their software implements the message types from NIP-01. It may implement NIP-11 to announce its capabilities. It may implement NIP-42 to require authentication. It may implement NIP-13 to require proof-of-work. It may implement NIP-40 to respect expiration tags. It may implement NIP-50 to provide search. It may implement NIP-65 to help users publish relay lists. It may implement NIP-66 to participate in relay discovery. It may implement any of the dozens of other NIPs that add functionality.

Each implemented NIP is a choice. The operator decides what kind of relay they want to run, what community they want to serve, what rules they want to enforce. The protocol enables these choices without mandating them.

§The User’s Perspective: Choosing Jurisdictions

From the user’s perspective, relays are jurisdictions to choose among. You are not forced to use any particular relay. You can select the ones that align with your values and needs.

Do you want permanent storage? Choose relays with long retention. Do you value privacy? Choose relays that don’t log IPs. Do you want to avoid spam? Choose relays that require proof-of-work. Do you want to support a particular community? Choose relays that specialize in that community’s content. Do you want to ensure your content reaches a wide audience? Publish to multiple relays with different policies.

You can also run your own relay, becoming your own jurisdiction. This is the ultimate sovereignty. You control the rules completely. Your content lives on your own server. You decide what to accept, what to store, what to forward.

NIP-65 lets you announce your relay choices. NIP-11 lets you learn about other relays’ choices. Together, they create a marketplace of jurisdictions where users can find the rules that suit them.

§The Network Effect of Sovereignty

When every relay is sovereign, the network as a whole becomes resilient. No single decision affects everyone. No single operator controls the conversation. No single jurisdiction can silence a voice.

If a relay becomes hostile, users leave. If a relay shuts down, content survives elsewhere. If a relay is captured by an attacker, the damage is contained. The network routes around failure because failure is always local.

This is the opposite of centralized platforms, where a single decision affects everyone. When Twitter bans someone, they are banned everywhere. When Facebook changes its algorithm, everyone’s feed changes. When YouTube demonetizes a channel, the creator loses income globally.

In Nostr, decisions are local. Their effects are limited. The network absorbs shocks that would shatter centralized systems.

§The NIPs as Constitutional Documents

The NIPs are not laws. They are possibilities. They describe what may be implemented, not what must be. This is the opposite of a centralized platform’s terms of service, which dictate what users must do.

A relay operator reading the NIPs sees a menu of options. They can implement authentication or not. They can require payment or not. They can support search or not. They can specialize in certain kinds or remain general. The choices are theirs.

A developer reading the NIPs sees a toolkit. They can build clients that use any combination of features. They can innovate without asking permission. They can create new kinds of events, new interaction patterns, new applications.

A user reading the NIPs sees a landscape of possibilities. They can choose relays that match their values. They can use clients that implement the features they want. They can participate in communities that form around shared interests.

The NIPs make this possible by documenting what exists without requiring what must be. They are a record of the network’s evolution, not a prescription for its future.

§Choosing Wisely

“Choose your jurisdictions wisely.” This is the advice for anyone entering the Nostr network. Your choice of relays determines what you see, who sees you, how long your content lasts, and what rules you live under.

Some relays are open and free, accepting anything from anyone. Some are restricted, requiring authentication or payment. Some are specialized, focusing on particular kinds of content. Some are ephemeral, storing nothing permanently. Some are archival, keeping everything forever.

None of these is wrong. Each serves a purpose. Each attracts a community. Each contributes to the diversity that makes the network resilient.

The wisdom is in understanding what you need and choosing accordingly. If you value permanence, choose archival relays. If you value privacy, choose relays that don’t log. If you value free expression, choose relays with minimal restrictions. If you value community, choose relays that host your tribe.

And if you value sovereignty above all, run your own relay. Become your own jurisdiction. Control your own rules. Participate in the network on your own terms.

This is what relays make possible. This is what the NIPs enable. This is the architecture of a network that cannot be controlled because it has no center to control.

§References

1. Nostr Protocol NIPs. Available at: https://nips.nostr.com
2. NIP-01: Basic protocol flow description
3. NIP-11: Relay Information Document
4. NIP-13: Proof of Work
5. NIP-40: Expiration Timestamp
6. NIP-42: Authentication of clients to relays
7. NIP-50: Search Capability
8. NIP-65: Relay List Metadata
9. NIP-66: Relay Discovery and Liveness Monitoring
10. NIP-86: Relay Management API

This essay was written for those who want to understand the territories they inhabit when they use Nostr. Every relay is a sovereign nation. Choose your jurisdictions wisely.