The Nostr protocol, explained in plain English

A protocol is a set of rules for how programs talk to each other. A platform is a company that runs those programs on your behalf. Twitter is a platform. Email is a protocol. Nostr is a protocol.

The distinction matters because protocols and platforms have different failure modes, different cost structures, and different futures. This guide explains what makes Nostr a protocol specifically, what that means in practice, and why the design stays small on purpose.

TL;DR. Nostr is a pub/sub messaging protocol with cryptographic signatures. It defines a small event format and a simple way for clients to send and receive those events via relays. No company owns it. Anyone can write a client, run a relay, or propose extensions. The core spec fits on a few pages.

When you are ready, grab your @nostr.blog address →

What a protocol actually is

Email is a good comparison. When you send an email from Gmail to Outlook, Gmail does not need Outlook's permission. Both services speak SMTP (the email protocol), and SMTP defines everything required for one mail server to hand a message to another. The servers are different companies. The protocol is a neutral agreement.

Nostr works the same way. A Nostr event (a post, a like, a follow) is a JSON object with a specific shape defined in the protocol. A relay is any server that agrees to accept, store, and forward events conforming to that shape. Any two clients that speak Nostr can interact through any relay that speaks Nostr, regardless of who made any of the three.

The protocol is a neutral agreement. The implementations are free to be anything.

The Nostr spec, in the fewest sentences

Three rules cover almost all of it.

1. An event is a JSON object with id, pubkey, created_at, kind, tags, content, sig. The id is a hash of the other fields; the sig is a Schnorr signature over the id using the pubkey's private counterpart.
2. A relay accepts valid events over WebSocket and serves subscriptions that filter events by author, kind, tag, or time.
3. A client signs events and publishes them to relays; reads events by subscribing to relays with filters.

That is the core protocol. Every advanced feature (long-form articles, zaps, DMs, communities, lists) is an extension that fits into this frame without changing it.

Why the protocol stays small

Most protocols grow by accretion. Every use case adds to the spec; every decade the spec is larger than the decade before. HTTP is now hundreds of pages. Email grew from a handful of RFCs to a thicket. Nostr has avoided this by design.

The mechanism is NIPs (Nostr Implementation Possibilities). New features are not added to the core spec; they are proposed as optional NIPs. Clients implement the NIPs they care about. Other clients ignore them. A popular NIP becomes part of the practical protocol because enough implementations speak it; an unpopular NIP fades without ceremony.

This means the core is forever small (the important invariants: signed events, open relays, portable identity) and the edges are forever flexible (new features evolve without breaking existing clients). A Nostr client from 2022 still works in 2026 because the core did not change; it just does fewer things than newer clients.

Protocol vs platform, concretely

Five practical differences you can feel as a user.

Identity. On a platform, your account is owned by the company. On a protocol, your account is a cryptographic identity you own. Nobody can take it away.

Data. On a platform, your posts live in their database. On a protocol, your posts live on multiple independent relays. If one goes away, the others still have them.

Feature velocity. On a platform, features ship when the company decides. On a protocol, features ship when any implementer writes them. This is slower in some ways (no central roadmap) and faster in others (many experiments in parallel).

Monetization. On a platform, the company captures all monetization. On a protocol, monetization is whatever the users and implementers agree to. Nostr has zaps (peer-to-peer tips over Lightning) because that fit the culture; a different protocol community might arrive at different norms.

Failure mode. A platform can go away entirely. A protocol cannot; as long as one implementer stays active, the protocol lives. Nostr is designed so that even if fiatjaf (the original author) disappeared tomorrow, the network would keep running without change.

What the protocol explicitly does not do

Five things left out of the spec on purpose.

Moderation. The protocol does not decide what content is acceptable. Each relay has its own rules; each client has its own filters; each user has their own mute list. Moderation happens at the edges, not the core.

Search. There is no protocol-defined search. Some relays index text; others do not. Clients that want search either rely on search-capable relays or run their own indexing. The absence is deliberate; it keeps the protocol neutral on what gets found.

Ranking. No "For You" feed. No engagement weighting. Clients display events by timestamp by default; any other ordering is a client-level decision, not a protocol one.

Discovery. No recommendation engine. Finding new accounts to follow is a client feature, not a protocol feature. Some clients invest heavily in this (Primal); others leave it to users (Damus).

Recovery. No account reset. Lose the private key, lose the account. The protocol could include key rotation but does not, because the tradeoffs are real and the community has not agreed on a specific mechanism yet. This is an ongoing area (NIP-26, NIP-41 drafts).

Each omission is a choice. Protocols stay small by refusing to solve every problem at the protocol level.

Who decides what Nostr becomes

Nobody and everybody.

There is no Nostr Foundation. No corporate working group. No steering committee. The most concentrated authority anywhere in the ecosystem is fiatjaf's GitHub repo where NIPs are proposed, and even that is just a coordination point, not a gatekeeper.

Proposed NIPs get read by client developers. Popular ones get implemented. A NIP that three major clients implement is effectively part of the protocol; a NIP that one developer wrote but nobody else cares about is just a document on GitHub.

This process is messy. There are coordination problems, duplicate proposals, and occasional politics. It is also resilient in a specific way: no single party can ruin it by making a bad decision, because bad decisions just do not get adopted. The protocol evolves in rough directions by the weight of developer choices, not by fiat.

When the protocol model wins

Protocols beat platforms in specific conditions:

• When ownership matters more than polish. Protocols are usually less polished than platforms. They win when you care about what the polish cannot give you (permanent identity, censorship resistance, open interoperability).
• When the network effect is the feature. A protocol's value grows with adoption by implementers, not just users. More clients and relays make the network stronger in ways a platform cannot copy.
• When the long-term horizon matters. Platforms get bought, sold, shut down, or pivoted. Protocols outlive any single implementer. Email is older than most companies; Nostr is betting on the same dynamic.

If your use case does not match any of these, a platform is usually faster and easier. This is honest. Nostr is not universally better than Twitter for every possible use. It is better in the specific ways a protocol beats a platform.

Reading the actual spec

If this guide made you want to read the protocol directly, the NIPs repository has the full list. NIP-01 is the core; the numbered NIPs after it are extensions. You do not need to understand any of it to use Nostr, but reading NIP-01 takes about ten minutes and clarifies a lot.