Nostr

Anna finds authors she wants to follow on Nostr. Later, she decides her app no longer suits her. If she safely uses the same private key or connected signing device in another app, she can keep the same identity. Her public key lets others recognize her and verify signatures; her private key lets someone sign as her. This is why npub and nsec are so different. Under NIP-19, they represent public and private keys in Bech32 encoding. NIPs are numbered documents describing Nostr rules and extensions. Encoding is not encryption: nsec is not a harmless profile link to share with anyone. Keeping an identity also does not automatically ensure that a new app will find every old post or import every setting. [2] [7]

The app, called a client, signs the post and sends it to selected relays. A relay is a server that accepts messages and stores or forwards them according to its own rules. Petr’s app connects to relays and requests posts he is interested in. There is no single central server and no requirement that every server copy everything. Technically, client and relay communicate over WebSocket, a connection kept open for ongoing messages: EVENT carries a message, REQ starts a subscription, and OK reports acceptance or rejection. Even a positive OK does not confirm delivery to Petr or permanent storage. EOSE marks the end of stored results for that query; the subscription can then continue with new messages. [1] [7]

When Petr receives a message, his app checks that its signature matches the stated public key and that the signed data has not changed. That does not establish whether the message is true or who the author is in real life. The author also supplies the creation time, so it is not an independent timestamp. For technically curious readers: a record called an event contains pubkey, created_at, kind, tags and content—the key, time, type, tags and message. SHA-256 turns their precisely specified encoding into a short checking value called id. It allows changes to the signed data to be detected. The sig field contains a Schnorr Signature under BIP340 on the secp256k1 curve. This says “the holder of the corresponding key signed this data,” not “this claim deserves your trust.” [1]

A long public key is difficult to remember. NIP-05 lets it be associated with an identifier shaped like an email address. The app asks the relevant domain which key belongs to that name and compares the answer with the profile’s key. This verifies a particular domain-to-key association, not automatically someone’s real name, reputation or reliability. The domain operator can later change the mapping. Once Anna follows someone, the original public key should remain decisive; assigning the same name to a different key should not silently change whom she follows. Pseudonymity means using a persistent identifier instead of a legal name, not a guarantee of anonymity. [3]

Petr need not download every message. He sends a filter, perhaps for posts by certain authors of a particular type. Different conditions within one filter use AND: all must hold together. Multiple allowed values for one condition are alternatives joined by OR, as are multiple filters within one REQ. Matching any of those filters is enough. limit restricts the initial set of stored results, not automatically future messages in the subscription. NIP-01 uses hexadecimal keys in events and filters rather than the user-facing npub format. An empty search result may be caused by the filter, the chosen server or its history; it does not prove that the post exists nowhere. [1]

Anna changes her profile description and wants others to see the new one. Nostr therefore distinguishes what relays should retain. For replaceable events, they select the newest record for the same pubkey and kind pair. Addressable events also use the value of the d tag, distinguishing, for example, separate documents by the same author. If replaceable records share a timestamp, the recommendation is to keep the lexicographically lower id—the one that comes first in the ordering of its written form. Ephemeral events are not even expected to be stored. These are conventions, and relay behavior may differ. Nostr is therefore not a ledger whose entire network agrees on one immutable history. [1]

Anna notices that she published something she meant to keep private. NIP-09 lets her send a signed deletion request. Before acting on it, a client must verify that the request and original post belong to the same public key; someone else cannot delete Anna’s post merely by referring to it. Cooperating servers and apps can remove or stop displaying the content. The request cannot remove every copy, screenshot or independent archive. Hiding a post in one app also says nothing about whether another server still offers it. What you publish matters more than whether a Delete button is available. [4]

Anyone who obtains a public post can read it; signing alone does not conceal its content. Private messages rely on additional rules. NIP-44 specifies content encryption, while NIP-17 describes wrapping and delivering messages with further protective layers. This does not automatically provide anonymity: network addresses, timing and app behavior can still reveal information. This encryption also lacks forward secrecy, protection for past conversations if a long-term key is later compromised. Someone who obtains the necessary private key and previously recorded ciphertext can read earlier messages too. Check which extensions a particular app actually supports; “Nostr” alone does not describe its privacy guarantees. [5] [6]