• The Moment of Creation
• NIP-01: The Basic Protocol Flow
• The Client’s Role: Creation and Signing
• Choosing Where to Send: Relay Selection
• The EVENT Message: Client to Relay
• Storage: The Relay’s Decision
• Subscription: How Readers Find Your Event
• The Outbox Model: Finding Everyone
• Replies and Threads: Building Conversation
• Private Messages: Encrypted Communication
• Zaps and Payments: Value Transfer
• The Relay’s Response: OK, CLOSED, NOTICE
• The Beauty of Optionality
• The State Could Be Better
• But the Design Is Better
• Following the Signature
• References

§The Moment of Creation

You write something. A thought, an observation, a question, a declaration. You press a button marked “publish” or “post” or simply “send.” In that instant, something happens that is both simple and profound. Your words are transformed from local data on your device into a cryptographically signed event that will travel across the internet, be stored on countless servers, and potentially reach eyes you will never know.

This transformation is the core of Nostr. It is not magic. It is not complex. It is a carefully designed sequence of steps, each specified by a NIP—a Nostr Implementation Possibility—that describes what may happen, not what must happen. The protocol enables. It does not mandate.

Understanding this journey is understanding how censorship-resistant broadcasting actually works. It is following the signature from your device to the world.

§NIP-01: The Basic Protocol Flow

Every journey begins with NIP-01. It is the foundation, the root, the specification that defines what an event is and how it moves.

An event, according to NIP-01, is a JSON object with a specific structure. It contains:

• id: the SHA-256 hash of the serialized event data
• pubkey: the public key of the event creator
• created_at: a Unix timestamp
• kind: an integer defining the type of event
• tags: an array of arrays, for additional metadata
• content: a string, the actual message
• sig: the cryptographic signature, proving authorship

This structure is everything. It is the atomic unit of Nostr communication. Every note, every reaction, every repost, every direct message, every piece of data that moves through the network is an event of some kind. And every event carries within it the proof of its own authenticity.

The signature is not an attachment. It is integral. It is what makes the event trustless. Anyone who has your public key can verify that you, and only you, could have created this event. No relay can fake it. No attacker can modify it. The signature binds the content to the creator forever.

This is the first and most important thing to understand about broadcasting on Nostr: your words carry your identity with them, permanently and verifiably.

§The Client’s Role: Creation and Signing

Your client is the software you use to interact with Nostr. It might be a web app, a mobile app, a desktop program, or even a command-line tool. Whatever its form, its first job is to help you create an event.

The client gathers your input—your text, your chosen kind, any relevant tags—and constructs the event object. It then does something critical: it asks for a signature.

How it asks depends on how your keys are managed. NIP-07 describes a window.nostr capability for web browsers, allowing web apps to request signatures without ever touching your private key. NIP-46 defines remote signing, so your keys can live on a secure device while your client runs elsewhere. NIP-55 covers Android signer applications. These specifications are all about keeping your key safe while still allowing you to sign events.

When you approve the signature request, your key signs the event. The signature is added to the event object. Now the event is complete. It is ready to travel.

Notice what has not happened yet. No relay has seen your words. No server has stored them. No network has transmitted them. The event exists only on your device, signed and sealed, waiting to be sent.

§Choosing Where to Send: Relay Selection

Your client now needs to decide where to send your event. This is not a random choice. It is guided by your preferences, your history, and the specifications that help clients make intelligent decisions.

NIP-65 describes relay list metadata. You can publish a kind 10002 event that lists the relays you use as outboxes—places where you want your content to be stored. Your client, knowing this list, will send your event to those relays.

But you might also want your event to reach people who don’t follow your outbox relays. If your event mentions someone, NIP-18 and NIP-27 describe how to handle references. Your client can look up the mentioned user’s relay list and send a copy there. If your event is a reply, NIP-10 provides guidance on threading and context.

The client is not just a dumb sender. It is an intelligent agent, making decisions about where your event should go to maximize the chance that interested parties will see it.

You can also override these decisions manually. Your client likely lets you choose specific relays for each post. The protocol does not restrict you. It only provides the tools.

§The EVENT Message: Client to Relay

When your client has chosen a relay, it opens a WebSocket connection and sends a message. The message type is EVENT. The content is your complete event object.

The relay receives this message. It performs a series of checks. Does the event have a valid signature? Is the kind acceptable according to the relay’s policies? Does the content violate any rules? Does the user have permission to post?

These checks are entirely up to the relay. NIP-01 defines the basic flow, but it does not mandate what relays must accept. A relay could accept everything. A relay could accept nothing. A relay could require payment, authentication, or proof-of-work. NIP-42 defines authentication of clients to relays. NIP-13 describes proof-of-work, which some relays might require to deter spam.

If the relay accepts the event, it sends back an OK message, confirming receipt. If it rejects the event, it sends a CLOSED message, possibly with a reason.

Your client receives this response. It may log it, display it, or simply move on. You, as the user, may never see this exchange. It happens in the background, in milliseconds, as your words travel to their first destination.

§Storage: The Relay’s Decision

Assuming the relay accepts your event, it now decides what to do with it. This decision is entirely the relay’s. The protocol imposes no requirements.

Some relays store everything forever. They are archives, preserving every event they receive. Some relays store only recent events, deleting older ones after a time. Some relays specialize in certain kinds of events—NIP-23 long-form content, NIP-71 videos, NIP-15 marketplace listings. Some relays are ephemeral, storing events only in memory and never persisting them to disk.

NIP-11 allows relays to publish information documents describing their policies. You can learn, before connecting, what a relay stores and for how long. NIP-40 lets events include expiration timestamps, telling relays when they can safely delete them.

Your event, once stored, becomes part of that relay’s database. It joins millions of other events, each signed, each verifiable, each waiting for someone to request it.

§Subscription: How Readers Find Your Event

Your event is now on one or more relays. But it is not yet seen. It is just data, sitting on servers, waiting to be requested.

When someone wants to see your content, their client sends a REQ message to relays. The REQ contains filters that describe what events they want. The filters might specify your public key, a date range, certain kinds, or specific tags.

NIP-01 defines the filter format. NIP-10 adds threading capabilities. NIP-50 describes search functionality. NIP-45 allows counting results without retrieving them.

The relay receives the REQ, checks its database for matching events, and sends back EVENT messages for each one. It also keeps the subscription open, sending new events as they arrive.

When the relay has sent all stored events that match the filter, it sends an EOSE message—End of Stored Events. This tells the client that it has received everything currently available, but new events may still arrive.

The client receives these events, verifies their signatures (again—verification is cheap and should never be skipped), and displays them to the user. Your words have reached their destination.

§The Outbox Model: Finding Everyone

The simple flow described above works well when readers know which relays to query. But how do they know where to look for your content?

This is the problem that NIP-65 solves. By publishing a kind 10002 relay list event, you tell the world where you post your content. Readers can look up this list and query those relays directly.

This is the outbox model. It is elegant in its simplicity. You post to your relays. Readers fetch from your relays. No central index required. No guessing where content might be.

NIP-65 also distinguishes between read relays and write relays. Write relays are where you post your content. Read relays are where you expect to receive replies and mentions. This separation allows for more sophisticated communication patterns.

The outbox model scales because it distributes the discovery problem. Instead of everyone trying to maintain a global index, each user maintains their own relay list. Clients aggregate these lists to find content.

§Replies and Threads: Building Conversation

A single event is just a statement. Conversation requires replies, threading, context.

NIP-10 defines how text notes and threads work. It introduces markers in the e tag to distinguish between replies, mentions, and root events. A reply includes references to the event it is replying to, allowing clients to build threaded views.

NIP-22 defines comments, which can be attached to any kind of event. NIP-25 covers reactions—likes, emoji, and other responses. NIP-18 describes reposts, allowing content to be shared with your own followers.

These specifications build on the basic event structure to create rich conversational possibilities. But they remain optional. Clients can implement the ones that make sense for their use case. The protocol does not force any particular interaction model.

§Private Messages: Encrypted Communication

Not all communication is public. NIP-17 defines private direct messages, replacing the deprecated NIP-04 with a more secure approach.

NIP-17 uses the same event structure as public messages, but the content is encrypted. Only the intended recipient, holding the corresponding private key, can decrypt and read it.

NIP-44 describes the encryption scheme in detail. NIP-59 adds “gift wrapping”—additional encryption layers that hide metadata about who is messaging whom. For truly private communication, NIP-EE (E2EE Messaging using MLS Protocol) is being developed, though currently unrecommended and superseded by other work.

The key insight is that privacy is built into the protocol, not added as an afterthought. Encrypted messages are just events with encrypted content. They travel through the same relays, use the same subscription mechanisms, and benefit from the same redundancy as public messages.

§Zaps and Payments: Value Transfer

Nostr integrates with Bitcoin’s Lightning Network through NIP-57, which defines Lightning Zaps. A zap is a payment attached to an event—a tip, a reward, a signal of appreciation.

The flow is more complex than a simple event. It involves zap requests (kind 9734) and zap receipts (kind 9735). It uses LNURL and bolt11 invoices. But the result is seamless: users can send small payments to content creators without leaving their client.

NIP-60 and NIP-61 extend this with Cashu wallets and nutzaps—private ecash that can be used for even more private transactions. NIP-75 defines zap goals for crowdfunding. NIP-87 helps discover ecash mints.

These payment specifications show how Nostr is not just a communication protocol. It is a foundation for economic interaction, with money moving as easily as messages.

§The Relay’s Response: OK, CLOSED, NOTICE

Throughout the broadcasting process, relays communicate with clients using a set of standard message types.

OK confirms that an event was accepted. It may include additional information about why the event was accepted or rejected.

CLOSED indicates that a subscription has been ended. It may include a reason, such as “auth-required: please authenticate” or “rate-limited: too many requests.”

NOTICE sends human-readable messages from the relay to the client. These might be informational, warnings, or errors.

NIP-01 defines these basic types. NIP-42 adds authentication flows. NIP-86 provides a relay management API for more advanced interactions.

The client interprets these messages and responds appropriately. It might try a different relay, prompt you to authenticate, or simply log the notice for debugging.

§The Beauty of Optionality

Looking at the NIPs, one thing becomes clear: almost everything is optional. NIP-01 is required for basic interoperability. Everything else is a possibility, not a requirement.

This is not a weakness. It is the source of Nostr’s flexibility. Different clients can implement different sets of NIPs, targeting different use cases and user preferences. Different relays can support different features, specializing in what they do best.

A simple microblogging client might implement only NIP-01, NIP-10, and NIP-65. A marketplace app would add NIP-15. A podcasting client would use NIP-23 for long-form content and NIP-57 for zaps. A privacy-focused messaging app would rely on NIP-17 and NIP-59.

All these applications share the same underlying protocol. All can interoperate where their feature sets overlap. None is forced to implement features it doesn’t need.

This is the opposite of centralized platforms, where the platform decides what features exist and everyone must use them the same way. In Nostr, features emerge organically as developers implement NIPs that solve real problems.

§The State Could Be Better

It would be dishonest to pretend that Nostr’s broadcasting system is perfect. It is not. The state could be better.

Discovery is still harder than it should be. New users often struggle to find interesting content and people to follow. The outbox model works, but it requires users to publish relay lists—something many forget to do.

Client implementations vary widely in quality and features. Some clients implement many NIPs; others implement only the basics. This fragmentation can confuse users who switch between clients.

Relay performance is inconsistent. Some relays are fast and reliable; others are slow and frequently offline. The network has no built-in quality control.

Scalability remains a question. Will the relay model hold up as user numbers grow into the millions? Will storage and bandwidth become prohibitive for volunteer-run relays?

These are real concerns. They are being worked on. New NIPs appear regularly, addressing these challenges. NIP-66 adds relay discovery and liveness monitoring. NIP-77 enables efficient syncing. NIP-86 provides management APIs. The protocol evolves.

§But the Design Is Better

Despite these limitations, the fundamental design of Nostr’s broadcasting system is better than the alternatives. Better than centralized platforms, where your words are held hostage to corporate policy. Better than federated systems, where your identity is tied to a server you don’t control. Better than blockchain-based social networks, where every post costs money and every user competes for block space.

The design is better because it separates concerns. The protocol handles verification. Relays handle storage. Clients handle discovery and display. Users handle choice. Each layer does one thing well, and none depends on any other.

The design is better because it is permissionless. You do not need anyone’s approval to speak. You do not need anyone’s permission to build a client. You do not need anyone’s blessing to run a relay. The network grows organically as people participate.

The design is better because it is resilient. There is no central point of failure. There is no single choke point for censorship. Your words can survive on any relay that chooses to keep them. Your identity cannot be taken away.

The design is better because it is extensible. New kinds of events can be added without changing the base protocol. New features can be implemented as NIPs, adopted gradually as they prove useful. The protocol does not need to anticipate every future use case. It just needs to provide the foundation.

§Following the Signature

At the end of this journey, we return to where we began: the signature.

Every event carries a signature. That signature is what makes the event yours. It is what allows anyone to verify that you, and only you, created it. It is what makes censorship so difficult—because even if a relay deletes your event, the signature proves it was yours. Even if someone tries to impersonate you, the signature proves they cannot.

When you hit publish, you are not just sending words into the void. You are broadcasting a signed statement that will exist as long as someone, somewhere, chooses to keep it. You are claiming authorship in a way that cannot be forged. You are making your mark on the network.

Follow the signature. It leads from your client to relays, from relays to readers, from readers back to you. It is the thread that connects every event to its creator, every message to its source, every word to its author.

This is broadcasting on Nostr. This is how your words travel from your client to the world.

§References

1. Nostr Protocol NIPs. Available at: https://nips.nostr.com
2. NIP-01: Basic protocol flow description
3. NIP-10: Text Notes and Threads
4. NIP-17: Private Direct Messages
5. NIP-57: Lightning Zaps
6. NIP-59: Gift Wrap
7. NIP-65: Relay List Metadata
8. NIP-42: Authentication of clients to relays
9. NIP-50: Search Capability
10. NIP-45: Counting results

This essay was written for those who want to understand what happens when they press publish. The journey is simpler than it seems. It is just events, signatures, and relays. Follow the signature, and you will find your way.