Nostr: A Decentralized Social Protocol Built on Nothing but Keypairs

No accounts. No servers, in the traditional sense. Nostr (Notes and Other Stuff Transmitted by Relays) is a strikingly simple decentralized social networking protocol proposed by the pseudonymous developer fiatjaf around 2020. Every identity is a keypair, and every piece of data is one single signed JSON structure. Here is how that extreme simplicity buys both censorship resistance and ease of implementation.

What Nostr is: identity as the keypair itself

Nostr has no central server that registers users or manages passwords and email addresses. What identifies a user is a secp256k1 keypair, the same elliptic curve Bitcoin uses. The public key is the user's unique ID, and signing with the private key proves "I really am the one who said this." The elliptic-curve cryptography here is not securing ownership of a currency; it is securing the authenticity of speech.

Raw key bytes are awkward for humans, so NIP-19 defines bech32-encoded representations: npub for the public key and nsec for the private key. There is no registration form and no login screen: the moment you generate a keypair, you have a new Nostr "account."

• Because no password or email address is ever handed to a server, it is structurally impossible for any operator to freeze or delete an account.
• The same keypair can be reused across multiple clients and multiple relays, so users are never locked into a single app or service.
• The flip side is that key custody is entirely the user's responsibility. Unlike cryptographic systems such as multisig, which formalize joint custody and recovery of keys, Nostr itself has no standard mechanism for key recovery or rotation.

Events: the single data structure Nostr is built on

Everything exchanged on Nostr, regardless of kind, is a signed JSON object called an event. Profile updates, posts, likes, follow lists: all of it is expressed through this one structure.

Together, id and sig let anyone verify, without trusting any relay or client, that "this event really was created by the holder of this public key, and it has not been altered since." Because a single integer, kind, switches the application-level meaning, new use cases can be added just by defining a new kind number in a NIP, from text posts to Lightning payment notifications to long-form articles.

Relays and NIPs: extensions layered on a deliberately "dumb" transport

The other core piece of Nostr is the relay. A relay accepts WebSocket connections, stores the events it receives, and forwards them to subscribers whose filters match, nothing more. It is deliberately simple, deliberately "dumb." Because an event's authenticity is already guaranteed by its signature, the relay itself never needs to do more verification than that, which keeps implementations extremely lightweight.

Crucially, relays do not talk to each other or synchronize with one another: they do not federate. In a federated architecture such as the archetypal ActivityPub, servers exchange information with each other at the protocol level; in Nostr, the entire burden of redundancy and availability sits with the client. A client writes the same event to several relays at once and subscribes to the people it follows across several relays in parallel. If one relay goes down, or starts censoring, the client simply switches to another; it is never expelled from the network as a whole.

• A relay operator is free to refuse to store or forward certain events (moderation on their own relay), but that never strips a user of their identity or their followers; the keypair and the social graph (who follows whom) are client-side state, not something any single relay owns.
• Relays can be free or paid, and anyone can run one. The protocol has no notion of authority or hierarchy among relays.

The core specification is deliberately minimal, and extensions are proposed and debated as numbered NIPs (Nostr Implementation Possibilities) on GitHub. Being able to add functionality just by giving new meaning to a kind or a tag, without touching the protocol itself, is what has let Nostr's ecosystem grow.

On top of this simple foundation, a wide range of clients have been built independently, including Damus on iOS and Amethyst on Android, and as long as two clients speak the same event format and relay protocol, they interoperate naturally.

Strengths and challenges

• Protocol simplicity: with a single event type and a thin relay role, both clients and relays can be implemented with relatively little code, and the protocol itself is easy to learn.
• Account suspension is structurally impossible: since identity is the keypair, no operator holds the power to "delete" an account. Being shut out of one relay never costs you your key or your social graph.
• Freedom to move between relays: switching away from a relay you dislike costs nothing, in contrast to ActivityPub, where migrating servers often comes with a break in continuity for the account.

• No recovery path if a key is lost or leaked: lose your private key and you permanently lose access to your identity, followers, and post history; leak it and there is no way to stop someone else from impersonating you. There is no standard mechanism for rotating keys, either.
• Spam mitigation is left to relays: the protocol itself imposes no cost on posting, so countermeasures such as NIP-13 Proof of Work or relays that charge for writes are left to the discretion of individual relay operators.
• De facto concentration on popular relays: anyone can in principle run a relay, but in practice connections and data tend to cluster on a handful of large ones, and there is weak economic incentive to maintain a broad set of highly available alternatives.
• Difficulty of global search and discovery: because relays do not federate, there is no single window for searching across "all of Nostr"; finding a particular post or user often means hopping between multiple relays.

Comparing Nostr, ActivityPub, and AT Protocol

All three protocols were born as pushback against centralized social media, but each makes a different call about where to place the root of trust. ActivityPub federates at the level of servers (instances); AT Protocol separates a recoverable identifier, the DID, from the PDS that hosts the data; Nostr places absolute trust in the keypair itself. Which one to reach for depends on how you weigh censorship resistance, recoverability, and implementation simplicity against each other.

Related pages

Nostr's design philosophy stands out most clearly against this site's other decentralization approaches. A federated architecture, and its archetype ActivityPub, where servers exchange information with one another, sits in sharp contrast to Nostr's deliberate choice that relays never federate. AT Protocol, another decentralized social protocol, grounds identity not in a raw public key but in a recoverable decentralized identifier (DID), one answer to the key-loss-means-total-loss problem Nostr still faces. The question of how a private key is stored and jointly custodied connects to multisig, and the idea of propagating events efficiently between relays echoes the anti-entropy thinking behind gossip protocols.