• The Two Directions of Communication
• Write Relays: The Outbox
• Read Relays: The Inbox
• How NIP-65 Makes This Possible
• The Flow: Sending a Note
• The Flow: Receiving a Reply
• The Flow: Reading a Followed User
• NIP-65 in Context
• The LearnNostr Perspective
• Strategies for Choosing Write Relays
• Strategies for Choosing Read Relays
• The Failure Modes
• The Philosophy of Separation
• The Practical Takeaway
• Your Outbox, Your Inbox
• References

§The Two Directions of Communication

Every communication system has two directions. There is the direction of sending: you have something to say, and you want it to reach the world. There is the direction of receiving: the world has something to say to you, and you want to hear it.

In centralized platforms, these two directions are fused. You send and receive through the same server, controlled by the same entity, governed by the same rules. The platform decides what you can send and what you can receive. The platform mediates every interaction.

Nostr separates these directions. You can choose different relays for sending and receiving. You can control where your words go and where you accept words from others. This separation is not a complication. It is a liberation.

Understanding the difference between write relays and read relays is understanding how Nostr gives you sovereignty over your communication.

§Write Relays: The Outbox

Write relays are where you publish your content. They are your outbox. When you create an event—a note, a reaction, a long-form article, anything—your client sends it to your write relays. The relays store it, and when other clients request it, they serve it.

Your write relays are your voice. They are where the world finds you. Choosing them is choosing how you are heard.

NIP-65 defines write relays as those with the "write": true marker in your kind 10002 event. These are the relays you declare as your outboxes. Clients that follow the outbox model will query these relays to find your content.

Why would you choose multiple write relays? For redundancy. If one relay goes offline, your content remains available on others. If one relay censors you, you still have a voice on others. If one relay is slow, others can serve your audience. Distribution is resilience.

Your write relays are your sovereign territory. You can run your own relay, giving you complete control. You can use public relays that align with your values. You can pay for relays that offer better performance. You can choose relays in different jurisdictions to protect against legal pressure.

The choice is yours. No one else makes it for you.

§Read Relays: The Inbox

Read relays are where you accept interactions. They are your inbox. When someone replies to you, mentions you, or sends you a direct message, they send it to your read relays. Your client queries these relays to find events that involve you.

Your read relays are your ears. They are where the world reaches you. Choosing them is choosing how you listen.

NIP-65 defines read relays as those with the "read": true marker in your kind 10002 event. These are the relays you declare as your inboxes. When someone wants to interact with you, they should send their events to these relays.

Why would you choose different relays for reading and writing? For separation of concerns. Your write relays might be under your control, accepting only your events. Your read relays might be public, accepting interactions from anyone. Or you might choose highly moderated read relays to filter spam, while posting your own content on free relays.

This separation gives you granular control. You can protect your own content while remaining open to interaction. You can curate your experience without imposing on others.

§How NIP-65 Makes This Possible

NIP-65 is the specification that enables the separation of read and write relays. It defines the kind 10002 event, which lists a user’s relays with optional read and write markers.

The markers are simple. If read is true, the relay should be used for fetching events that reference the user. If write is true, the relay should be used for publishing the user’s own events. A relay can be both, one, or neither.

This flexibility allows for sophisticated strategies:

• The Self-Hosted Writer: Run your own relay for writing. List it as write-only. Use public relays for reading.
• The Privacy-Conscious: Use write relays that don’t log IPs. Use read relays that require authentication to prevent spam.
• The Censorship-Resistant: Distribute your write relays across multiple jurisdictions. Use read relays that are equally distributed.
• The Community Member: Write to relays shared with your community. Read from the same relays to see interactions.

NIP-65 does not mandate any particular strategy. It enables all of them.

§The Flow: Sending a Note

When you publish a note, your client:

1. Constructs an event with your content.
2. Signs it with your private key.
3. Sends it to your write relays (those with "write": true in your kind 10002).
4. Waits for OK responses confirming receipt.

That is the entire flow. Your note is now on your write relays, waiting for readers.

Notice what does not happen. Your client does not send your note to random relays. It does not spray your content everywhere. It does not rely on anyone else’s decisions. It follows your declared preferences.

This is sovereignty in practice.

§The Flow: Receiving a Reply

When someone replies to your note, their client:

1. Fetches your kind 10002 event.
2. Identifies your read relays (those with "read": true).
3. Sends their reply to those relays.

Your client, when it checks for interactions, queries your read relays. It subscribes to events that reference your public key. When a reply arrives, it appears in your feed.

Notice what this achieves. The reply reaches you even if you and the replier use completely different relay sets. Your write relays are irrelevant to receiving replies. Your read relays are the only thing that matters.

This is why separation is powerful. You can post on your own relay, in your own jurisdiction, under your own rules. You can still receive replies from anyone, anywhere, as long as they know your read relays.

§The Flow: Reading a Followed User

When you want to read content from someone you follow, your client:

1. Fetches their kind 10002 event.
2. Identifies their write relays (those with "write": true).
3. Subscribes to events from their public key on those relays.

Your feed is built from the write relays of the people you follow. You are not dependent on any single relay. You are not at the mercy of an algorithm. You are following your chosen connections to their chosen outboxes.

This is the outbox model in action. It is efficient, resilient, and user-controlled.

§NIP-65 in Context

NIP-65 does not exist in isolation. It interacts with other specifications that extend its functionality.

NIP-01 provides the basic protocol flow. Without events, signatures, and message types, there would be nothing to publish or subscribe to.

NIP-51 defines the list framework. Kind 10002 is a specific type of list, following the patterns established for replaceable lists.

NIP-11 allows relays to announce their capabilities. When you choose relays, you can check their information documents to see what they support.

NIP-42 provides authentication. If your read relays require authentication, your client must handle that.

NIP-17 defines private direct messages. For DMs, the flow is slightly different: you list your DM relays separately (kind 10050), and your client handles encryption.

These specifications work together to create a coherent system. NIP-65 is the linchpin, the specification that ties relay choices to user identity.

§The LearnNostr Perspective

The tutorial from LearnNostr.org emphasizes the practical side of relay communication. It notes that relays are “simple servers that store events submitted by clients and serve events to clients based on filters.” This simplicity is the foundation upon which complexity is built.

The tutorial also stresses best practices: use multiple relays, handle failures gracefully, monitor health, deduplicate events, limit subscriptions. These practices are especially important when using separate read and write relays. Your client must manage multiple connections, handle failures independently, and aggregate events from diverse sources.

The separation of read and write relays increases complexity, but it also increases resilience. A well-implemented client can handle this complexity. The user, meanwhile, enjoys the benefits without seeing the machinery.

§Strategies for Choosing Write Relays

Your write relays determine where your voice is heard. Here are some strategies:

The Self-Hosted: Run your own relay. You control everything. Your content lives on your hardware. You answer to no one. The downside: you must maintain it.

The Distributed: Use multiple write relays across different jurisdictions. If one is pressured, your content survives on others. The downside: you must manage multiple accounts or payments.

The Community: Write to relays that your community uses. Your content is more discoverable. The downside: you are dependent on those relays’ policies.

The Paid: Pay for write relays that offer better performance, longer retention, or stronger privacy guarantees. The downside: it costs money.

The Free: Use free public relays. They are convenient, but you have no guarantees. The downside: they may disappear or change policies.

None of these is universally correct. The right choice depends on your needs, your threat model, and your resources.

§Strategies for Choosing Read Relays

Your read relays determine what you hear. Here are some strategies:

The Open: Use public relays that accept all interactions. You hear everything, including spam. The downside: noise.

The Filtered: Use relays that moderate content. You see only what passes their filters. The downside: you may miss something.

The Community: Read from relays where your community interacts. You see the conversations that matter to you. The downside: you may miss outside perspectives.

The Private: Use read relays that require authentication. You control who can interact with you. The downside: barriers to interaction.

The Distributed: Use multiple read relays to ensure you don’t miss anything. The downside: more connections to manage.

Again, there is no single right answer. You might use different strategies for different types of interaction. You might use one set of relays for public interactions and another for direct messages.

§The Failure Modes

Separation of concerns introduces new failure modes. Your write relays might be up while your read relays are down. You can still publish, but you cannot see replies. Your read relays might be up while your write relays are down. You can still see replies, but you cannot publish.

These are not catastrophic failures. They are degraded states. And they are preferable to the alternative: a single point of failure that takes down everything.

The system is designed for graceful degradation. If a write relay fails, you can publish to others. If a read relay fails, you can read from others. If all your relays fail, you can choose new ones. Your identity persists. Your content survives.

This resilience is the point. The separation of read and write relays is not an accident. It is a design for survival.

§The Philosophy of Separation

The separation of read and write relays reflects a deeper philosophy: that sending and receiving are distinct activities that should be controlled separately.

In centralized platforms, sending and receiving are fused. You send through the platform, and you receive through the platform. The platform controls both. It decides what you can say and what you can hear.

In Nostr, you control both, separately. You choose where your words go. You choose where you listen. No one else makes these choices for you.

This is not just technical. It is political. It is the architecture of a system that respects user sovereignty. It is the implementation of the principle that you should control your voice and your ears.

§The Practical Takeaway

For the user, the separation of read and write relays means:

• You are not tied to any single relay.
• You can migrate your presence without losing your audience.
• You can curate your experience without imposing on others.
• You can protect your content while remaining open to interaction.
• You can choose different strategies for different needs.

For the developer, it means:

• Clients must implement the outbox model for discovery.
• Clients must handle multiple connections gracefully.
• Clients must respect the read/write markers in kind 10002.
• Clients must provide interfaces for managing relay choices.

For the relay operator, it means:

• Relays can specialize. Some may be write-only, some read-only, some both.
• Relays can compete on different dimensions: performance, privacy, retention, cost.
• Relays are not required to serve all functions.

§Your Outbox, Your Inbox

Your outbox is where you put things. Your inbox is where you accept things. These are separate functions, and they should be under separate control.

Nostr gives you this control. Through NIP-65 and the kind 10002 event, you declare your write relays and your read relays. Clients respect your choices. The network adapts to your needs.

You can post on a relay you run yourself, in a jurisdiction you trust, under rules you set. You can receive replies on public relays that are open to the world. You can change your mind at any time, updating your relay list and moving your presence.

This is sovereignty. This is freedom. This is what happens when you separate the directions of communication and put control where it belongs: with the user.

§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-17: Private Direct Messages
5. NIP-42: Authentication of clients to relays
6. NIP-51: Lists
7. NIP-65: Relay List Metadata
8. NIP-66: Relay Discovery and Liveness Monitoring
9. LearnNostr.org. (2025). Relay Communication. Available at: https://www.learnnostr.org/tutorials/relay-communication
10. Dilger, M. (2023). The Gossip Model. Available at: https://mikedilger.com/gossip-model/

This essay was written for those who want to understand how Nostr gives you control over your voice and your ears. Your outbox is where you put things. Your inbox is where you accept things. Choose wisely.