Nostr

Nostr (Notes and Other Stuff Transmitted by Relays) is an open, decentralized protocol for a global social network, defined by a set of simple, non-proprietary standards. Unlike traditional platforms, Nostr has no central servers, company, or single point of failure. Instead, it operates on a federated model of independent relays and user-controlled cryptographic key pairs. Users publish signed events—such as text notes, reactions, or metadata—to any relays they choose, and clients fetch data from multiple relays to construct a unified feed. This architecture makes the network resilient and resistant to censorship or deplatforming.

The protocol's core components are public-private key pairs and relays. A user's identity is their public key (often shown as an npub1... address), and their private key signs all content, proving authorship. Relays are simple servers that receive, store, and broadcast events from users; anyone can run a relay, and users can publish to or read from as many as they wish. This creates a competitive relay ecosystem and prevents any single entity from controlling the network. The most common client implementation is Damus, but many independent clients exist, all interoperating via the same protocol.

Nostr's design emphasizes simplicity and interoperability. Its specification is intentionally minimal, focusing on a small set of event kinds (like kind:1 for text notes). This allows for rapid client innovation and specialization—from microblogging to long-form articles, direct messaging, and even decentralized identity. A key feature enabled by cryptographic signatures is zaps, which are small Bitcoin Lightning Network payments that can be attached to notes as monetized likes or tips, creating a native value layer without platform intermediaries.

The protocol addresses several limitations of both traditional social media and other decentralized alternatives. Compared to federated networks like ActivityPub (used by Mastodon), Nostr has no concept of a "home server"—a user's data is not tied to a single instance, eliminating migration headaches. Its relay-based model also avoids the complex server-to-server synchronization of federation. While still evolving, Nostr has gained significant traction for its developer-friendly approach, strong censorship resistance, and the vibrant, multi-client ecosystem it fosters.

Nostr is a recursive acronym for "Notes and Other Stuff Transmitted by Relays." This naming convention, where the acronym's first letter refers to the acronym itself, is a hallmark of hacker culture and open-source projects (e.g., GNU's "GNU's Not Unix"). The name immediately signals the protocol's two fundamental components: notes (the decentralized social posts or events) and relays (the simple, distributed servers that broadcast them).

The choice of "Notes" over "messages" or "tweets" is deliberate. It emphasizes simplicity, permanence, and a broader utility beyond mere social media. A note can be a short post, a long-form article, a cryptographic proof, or a structured data event, making the protocol a general-purpose data broadcast system. The term "Relays" evokes a network of independent, non-custodial pass-through servers, contrasting with centralized "servers" or "platforms" that host and control user data.

The etymology underscores Nostr's foundational principles: simplicity in its client-relay model, decentralization through its relay-based architecture, and resilience via its open protocol standard. Unlike branded platforms (Twitter, Facebook), the name describes a function, not a company, aligning with its permissionless, identity-agnostic design where anyone can run a relay or build a client without a central authority.

The Nostr protocol operates on a simple, decentralized architecture built around two core components: clients and relays. A client is any software application—like a web app, mobile app, or desktop client—that a user interacts with to create, sign, and publish content. A relay is a simple server that receives messages from clients and broadcasts them to other connected clients. Unlike traditional platforms, there is no central server; anyone can run a relay, and users can connect to multiple relays simultaneously for redundancy and censorship resistance. This separation of data storage (relays) from the user interface (clients) is a fundamental design principle.

User identity and data integrity are secured through public-key cryptography. Each user is identified by a public key, which serves as their permanent, self-sovereign identifier (e.g., npub1...). The corresponding private key is kept secret and is used to cryptographically sign every piece of data, or event, the user creates. An event is a JSON object containing the message content, a timestamp, a kind (which defines the event type, like a note or metadata), and the user's signature. Relays store and broadcast these signed events, but they cannot forge them, ensuring the authenticity and integrity of all data on the network.

The protocol defines specific event kinds to structure different types of content. The most common is Kind 1, which is a short text note, the equivalent of a "tweet" or post. Other kinds handle user metadata (Kind 0), encrypted direct messages (Kind 4), reaction emojis (Kind 7), and more. Clients interpret these kinds to render a familiar social media experience. A user's complete social graph and history are not stored in one place but are assembled by their client, which fetches their events and the events of the people they follow from all the relays they are connected to, creating a personalized feed from the decentralized data layer.

A Nostr Improvement Proposal (NIP) is a formal design document that introduces new features, standards, or best practices to the decentralized Nostr protocol. Each NIP provides the technical specifications required for interoperability between different clients and relays. The process is community-driven: anyone can propose a NIP by submitting a draft to the official repository, where it undergoes review and discussion before being assigned a number and status (Draft, Final, or Deprecated). This open governance model allows the protocol to evolve without a central authority.

NIPs are categorized by their function. Core NIPs (e.g., NIP-01) define the foundational protocol, including event formats, cryptographic signing, and basic relay behavior. Standard NIPs establish common features like direct messaging (NIP-04), reactions (NIP-25), and replaceable events (NIP-16). Optional NIPs propose experimental or application-specific extensions, such as decentralized identity (NIP-05) or long-form content (NIP-23). This modular structure allows developers to implement only the standards relevant to their application while maintaining a base level of network compatibility.

For developers, implementing NIPs correctly is critical for ensuring their client or relay can communicate with the broader Nostr ecosystem. A client that supports a wider range of NIPs can offer more features, like encrypted chats, profile metadata, or custom event types. Relays may choose which NIPs to support, influencing the types of data they store and broadcast. The canonical list of NIPs serves as the definitive technical reference, and the protocol's evolution is transparently tracked through the acceptance and implementation of these proposals across the network.