Basic Protocol Flow
The foundational specification defining how Nostr works: events, clients, relays, and basic protocol operations.
Nostr Implementation Possibilities — the technical specifications that define how Nostr works. From basic protocol operations to advanced features.
The foundational specification defining how Nostr works: events, clients, relays, and basic protocol operations.
Defines how Nostr users maintain their following lists, organize contacts with custom names, and manage their social graph.
Defines how Nostr users send private, encrypted direct messages using kind 4 events and ECDH encryption.
Mapping Nostr public keys to human-readable internet identifiers using DNS and HTTPS, enabling verified usernames like alice@example.com.
Defines window.nostr API for browser extensions to provide signing capabilities to web applications without exposing private keys.
Defines how users can request deletion of their previously published events using kind 5 deletion events.
Defines conventions for using e and p tags in replies to create threaded conversations and proper mention attribution.
Defines proof-of-work system for Nostr events, requiring computational effort to combat spam and abuse.
Defines human-friendly bech32 encoding for Nostr entities (public keys, event IDs, etc.) using prefixes like npub, nsec, note, and nevent.
Defines nostr: URI scheme for creating universal links to Nostr profiles, notes, and other entities across clients and platforms.
Defines how to publish long-form content like articles and blog posts on Nostr using parameterized replaceable events.
Defines how users express reactions (likes, emoji responses) to events using kind 7 reaction events.
Defines how to embed nostr: references inline in text content, enabling rich mentions and content previews within notes.
Defines public chat channels using kind 40 (channel creation), kind 41 (channel metadata), and kind 42 (channel messages).
Defines parameterized replaceable events (kinds 30000-39999) with unique identifiers, enabling updatable content with stable addresses.
Defines challenge-response authentication mechanism allowing relays to verify client identity before granting access.
Defines how relays can provide search functionality by supporting 'search' filter parameter for full-text and keyword searches.
Defines how users can create and manage categorized lists for bookmarks, mutes, pins, and other collections on Nostr.
Defines how to send Bitcoin Lightning payments (zaps) to Nostr events and users, integrating value-for-value payments directly into the protocol.
Defines how users specify their preferred relays for reading and writing events, enabling better content discovery and delivery.
Nostr Implementation Possibilities are the technical specifications that define how the Nostr protocol works. Think of them as building blocks—each NIP adds a specific feature or capability.
NIPs ensure interoperability. When clients implement the same NIPs, they can communicate seamlessly. You can post in Damus and see it in Primal because both follow NIP-01.
NIPs cover everything from core protocol (events, relays) to social features (DMs, reactions) to advanced use cases (marketplaces, media).
Final = stable and widely implemented. Draft = in development, may change. Deprecated = replaced by better alternatives.
New to Nostr? Start with these fundamental specifications.
The foundation of Nostr. Defines events, clients, relays, and basic operations. Start here if you're learning how Nostr works.
Human-readable identifiers like alice@example.com. Essential for discoverability and identity verification.
User-friendly formats like npub and note. Makes sharing public keys and event IDs easy.