Nostr is an open protocol for signed events exchanged by clients through independent relays. Social networking is one use; the protocol has no blockchain of its own or shared consensus across all relays.
An event contains pubkey, created_at, kind, tags, content, id and sig. NIP-01 derives id with SHA-256 from a precisely specified serialization and uses BIP340 signatures on secp256k1. Clients verify integrity and key authorization. The author supplies created_at; it is neither an independent timestamp nor evidence that the content is true. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
A client publishes EVENT and subscribes using REQ over WebSocket. An OK response reports acceptance or rejection by that particular relay. EOSE ends the stored-event listing, not necessarily the subscription to new events. None of these messages confirms recipient delivery, network-wide replication or permanent storage. [Nostr — NIP-01: Basic protocol]
Within one filter, an event must meet every specified condition: author and kind mean AND. Multiple filters in one REQ are combined with OR; matching one is enough. limit constrains the initial listing, not the number of future events. A missing result may reflect a relay’s limited history, not an event’s nonexistence. [Nostr — NIP-01: Basic protocol]
Replaceable events are compared by pubkey and kind; addressable events additionally use the d tag. A newer version can replace an older one; equal timestamps are resolved by the lexicographically lower id. Ephemeral events are not expected to be stored. These rules describe relay behavior, not an immutable global archive; implementations may differ. [Nostr — NIP-01: Basic protocol]
NIP-19 uses Bech32 for user-facing encoding: npub means public key and nsec private key. Encoding is not encryption. Sharing nsec therefore hands over the secret key, not merely a profile link. NIP-01 events and filters use hexadecimal public keys, not their npub display form. [Nostr — NIP-19: Encoded entities]
NIP-05 associates an email-like name with a public key using the domain’s response. It establishes that association, not a person’s real identity or honesty. Clients should follow the original key: if a domain remaps a name to another key, it must not automatically substitute that key for the previously followed profile. [Nostr — NIP-05: Internet identifiers]
NIP-09 defines an author’s request to remove their events. Before hiding one, a client should check that the original event and request have the same public key. Relays and clients may process the request, but the protocol cannot remove every previously downloaded or otherwise retained copy. Deletion in one interface is not evidence of global erasure. [Nostr — NIP-09: Deletion requests]
NIP-44 defines an encrypted payload, not a complete private messaging system; NIP-17 adds wrappers and delivery rules. NIP-44 alone does not provide forward secrecy after a later key compromise. Network addresses, timing and client behavior remain relevant even with encrypted content. Support for particular NIPs must be distinguished by application. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
For the clearest picture, read this entry together with Nostr Wallet Connect, Schnorr signature, Private Key, Bitcoin Privacy, Pseudonymity. The reverse links also lead from Nostr Wallet Connect.