What Is the Nostr Protocol? Architecture, Features, and How It Works

• Identity is a keypair: A Nostr identity is based on a secp256k1 keypair and can be reused across compatible clients and relays.

• Events are the only object type: Each Nostr message is a signed JSON event with id, pubkey, created_at, kind, tags, content, and sig.

• Relays do not federate: NIP-01 does not define relay-to-relay federation, so clients typically publish to multiple relays for redundancy and reach.

• Signatures prove authorship, not privacy: A signature proves which key wrote an event, and NIP-01 content stays public unless a client encrypts it.

• Nostr omits agent coordination: The protocol carries identity and messages, and defines no capability discovery, task state, or authority scoping for agents.

If you're asking 'what is the Nostr protocol?', the simplest answer is that Nostr is a specification for exchanging signed JSON events between clients and relays over WebSocket connections. The name is an acronym: Notes and Other Stuff Transmitted by Relays.

Two facts define the architecture. Identity is a secp256k1 keypair the user generates locally. Distribution runs across independent relay servers that share no state.

The rules live in the NIPs repository, short for Nostr Implementation Possibilities. NIP-01 calls itself the basic protocol everyone should implement. Everything else, from long-form articles to git patches, arrives as an optional event kind layered on the same object.

Nostr was created to remove the platform from the middle of the identity relationship. That goal is central to any useful Nostr protocol description, because decentralizing identity is not just a side effect of the architecture. On a centralized service, an account is a database row the operator controls, and the operator can rename it, delete it, or make it unreachable.

Nostr moves that record to the user. The user generates a key locally and registers it nowhere. A relay can refuse to store events from a given key, but the refusal is local: the same key publishes elsewhere and keeps its followers, history, and handle intact.

The protocol repository credits fiatjaf with the initial description of the idea, and borrows the cryptography from Bitcoin: the secp256k1 curve and BIP-340, itself a Bitcoin Improvement Proposal. NIP-01 requires no blockchain, token, or payment.

Nostr's base security model starts with signed events: clients verify a Schnorr signature over each event and can detect tampering without trusting the relay; the signature is produced with the author's secp256k1 key and verified against the BIP-340 standard.

The Nostr protocol explained through that single operation gives you the whole security model:

• Any client can confirm an event came from a specific public key without asking a relay to vouch for it.

• A relay that edits content, created_at, or tags breaks the id hash and invalidates the signature, so readers detect the tampering.

• A relay can still drop events, delay delivery, or serve a partial view.

Two limits matter before building on this. NIP-01 content is plaintext, so confidentiality needs a layer such as NIP-44 encrypted payloads or NIP-17 private direct messages. Relay authorization is optional: NIP-42 defines a AUTH challenge and a kind: 22242 event for gating reads and writes, and a relay is free to skip it.

A more technical overview of the Nostr protocol starts with the four components involved in every basic exchange. A working Nostr protocol description has four parts: the event, the keypair, the relay, and the client.

The event is the only object type in the system. A note, a profile, a reaction, and a git patch are all the same shape with a different kind value:

{
  "id": "<32-byte hex sha256 of the serialized event>",
  "pubkey": "<32-byte hex public key of the author>",
  "created_at": 1786320000,
  "kind": 1,
  "tags": [["p", ""]],
  "content": "text or a kind-specific payload",
  "sig": "<64-byte hex Schnorr signature>"
}

The other three parts stay deliberately small:

• Keypair. The private key signs, and the public key is both the identity and the address. A kind: 0 event carries the profile metadata for that key.

• Relay. A WebSocket server that accepts EVENT messages and answers REQ subscriptions, then sends EOSE once the stored backlog is exhausted.

• Client. Holds or delegates the key, signs events, and fans them out to several relays at once.

NIP-01 defines no relay-to-relay synchronization, so clients primarily handle redundancy by publishing and reading across multiple relays.

For people, the practical payoff is publishing that survives deplatforming. A writer working under a key can be dropped by any relay and stay reachable, because readers follow a public key and query whatever relays still carry its events.

The mechanics are ordinary. A client posts a kind: 1 note to five relays. A reader's client sends a REQ filtered on authors and collapses the duplicates it gets back, because the id is a hash of the event itself.

What people give up is the convenience layer a platform provides. Username lookup exists only where a client implements NIP-05 DNS identifiers; a leaked private key has no recovery path; and search works only when a relay offers it.

Yes, and the reason is narrower than it first sounds. An agent can hold a keypair, sign events, and publish to relays just like a human client. That solves one real problem: an agent built on one stack cannot currently prove it is the same agent after moving to another.

Block shipped the most visible production case. Buzz, open-sourced in July 2026 under Apache 2.0, is a self-hostable workspace where people and agents share channels on a relay the team owns, running NIP-01 events with NIP-42 authentication underneath. Block's launch post names identity as the reason for the choice: an agent's keypair belongs to the agent, not the platform it happens to run on.

The base protocol does not define agent coordination semantics such as capability discovery, task lifecycle, acceptance state, or delegated authority.

A2A covers part of that with capability metadata and a task lifecycle, and the ACP protocol and MCP define their own contracts. That is why agent communication protocols are compared on discovery and task state rather than transport.

Every property Nostr gains by removing the coordinator has a matching cost that the client absorbs.

Durability becomes "publish to five relays." Trust becomes "verify every signature yourself." Both are cheap for a social client reading a few hundred events a minute, and expensive for an agent fleet reading everything.

The near-term direction shows up in the NIPs repository, not in predictions. Newer NIPs increasingly add group, access, and trust metadata on top of the basic signed-event model, showing how the ecosystem is experimenting with richer coordination and authorization semantics.

For AI systems, the open question is whether keypair identity becomes the default way agents prove who they are across vendors. Nothing makes that inevitable, but it does make the experiment cheap: an agent needs a key and a relay URL.

What Nostr will not answer is what happens after the message arrives. Delegation needs a record of who asked, who accepted, what authority traveled with the request, and what happened when it failed. Those are runtime concerns sitting above any transport.

Once Nostr provides portable identity and message transport, teams still need runtime coordination around discovery, routing, delivery state, recovery, and authority. BAND addresses that operational layer rather than replacing the underlying protocol.

BAND supplies that layer. Its agent registry records ownership and three-tier visibility per agent; ChatRoom routing delivers messages only to mentioned agents; delivery tracking moves each message through delivered, processing, and processed or failedand native adapters connect LangGraph, CrewAI, and A2A endpoints without per-pair glue code. BAND does not replace open protocols, and it is not a model evaluation or drift monitoring tool. The BAND platform runs the agent-to-agent communication that protocols only specify.

To see how registry, routing, and recovery behave against agents you already run, book a demo.