Note

A Deletion Request Is Not Erasure: What Nostr Kind 5, Kind 62 and Expiration Actually Do

On Nostr, deletion is a signed request addressed to relays and clients, not an operation on the network. Kind 5 asks, kind 62 binds supporters, and expiration is a hint — none of them erases every copy.

2026-10-28 · nostr, nip-09, nip-62, nip-40, nip-01, nip-11, deletion, right-to-be-forgotten, relays, civil-liberties

Listen · 10 min · AI voice

Dark CryptoDecentral hex mesh — one teal cell near the centre is fading toward transparency while faint bronze echoes of it persist in scattered distant cells across the mesh; no text.

Most people learn how deletion works on centralised platforms: you press a button, one company removes the row from its database, and the post is gone from that service (if not from screenshots). Nostr has no single database. A note you publish is a signed event, copied to every relay you sent it to, every relay that someone else rebroadcast it to, and every client cache that fetched it.

So what does "delete" mean on a network where nobody holds the master copy? The NIPs repository gives three separate answers, and they are easy to confuse.

Thesis, stated once: on Nostr, deletion is a signed request addressed to relays and clients, not an operation performed on the network. Kind 5 asks politely, kind 62 asks firmly, and an expiration tag is a hint. None of them reaches a copy held by someone who chooses not to listen. Publish with that in mind, and use the deletion tools for what they actually do.

Kind 5: a deletion request, and the name is deliberate

NIP-09 is titled "Event Deletion Request", not "Event Deletion". It defines a kind 5 event carrying one or more e tags (event ids) or a tags (addresses of replaceable or addressable events), each "referencing an event the author is requesting to be deleted". It SHOULD include a k tag for the kind of each referenced event, and the content MAY carry a reason.

What each party is asked to do is spelled out:

Relays "SHOULD delete or stop publishing any referenced events that have an identical pubkey as the deletion request." That is a SHOULD, not a MUST, and "stop publishing" is explicitly allowed as an alternative to deleting.
Relays SHOULD keep the request itself "indefinitely, as clients may already have the event that's intended to be deleted." The deletion request is meant to outlive the thing it deletes, so that late-arriving clients still learn about it.
Clients SHOULD hide the referenced events or mark them, and MAY show them "along with an icon or other indication that the author has 'disowned' the event." Clients SHOULD also rebroadcast the request to relays that don't have it.
For a tags, relays SHOULD delete "all versions of the replaceable event up to the created_at timestamp of the deletion request event." A later version with the same address is not covered.

Two rules are easy to miss. First, a deletion request against a deletion request "has no effect", so there is no undo. Second, the spec is candid about scope: clients "MAY choose to inform the user that their request for deletion does not guarantee deletion because it is impossible to delete events from all relays and clients."

Why the pubkey check matters, and who must do it

A kind 5 event is signed by its author, but it names other events by id. Nothing stops anyone from publishing a kind 5 that references your note. NIP-09 handles that with a pubkey rule, and it splits the job carefully.

Clients carry the hard requirement: a client "MUST validate that each event pubkey referenced in the e tag of the deletion request is identical to the deletion request pubkey, before hiding or deleting any event." The spec then adds: "Relays can not, in general, perform this validation and should not be treated as authoritative." A relay may never have seen the referenced event, so it can't always check whose it was. Relay-side validation is only a MAY.

This is a good example of why we pull spec text from source. Nostrbook's kind 5 page is a faithful summary in most respects, but in its client section it says clients "SHOULD" validate the pubkey match. The NIP says MUST. If you're building a client, the difference decides whether a stranger can make your users' feeds hide your posts. Read 09.md.

Kind 62: a request to vanish, aimed at operators

NIP-62, "Request to Vanish", is a different tool with a different audience. Kind 5 is about specific events. Kind 62 asks a relay to delete everything from a pubkey up to the request's created_at, including earlier NIP-09 deletion requests.

The language is stronger. The NIP opens by noting this procedure "is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database." For a relay whose URL appears in a relay tag:

it "MUST fully delete any events from the .pubkey";
it SHOULD delete NIP-59 gift wraps that p-tag the pubkey, which means the DMs addressed to it;
it "MUST ensure the deleted events cannot be re-broadcasted into the relay";
paid or restricted relays "MUST also follow the request to vanish regardless of the user's status."

A request can name specific relays, and clients SHOULD send it only to them. Or it can use the uppercase value ALL_RELAYS, in which case clients SHOULD broadcast it as widely as possible. As with kind 5, a kind 5 against a kind 62 "has no effect"; there is no unvanish.

The key word is still supporters. The MUSTs bind relays that implement NIP-62. A relay that never adopted it is under no protocol obligation, and an ALL_RELAYS request can't reach a relay it is never sent to. NIP-62 gives an operator who wants to honour erasure a clean, signed, machine-readable instruction. It does not give you a lever over operators who don't. Whether a particular law obliges a particular operator is a legal question about that operator, not something the event itself decides.

Expiration: a hint about the future, not a timer

NIP-40 adds an expiration tag with a Unix timestamp after which an event "SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays." Read the relay section closely: relays "MAY NOT delete expired messages immediately on expiration and MAY persist them indefinitely." They SHOULD NOT serve expired events and SHOULD drop expired events published to them. Clients SHOULD NOT send expiration events to relays that don't advertise NIP-40.

The NIP's own warning is the best summary: "The events could be downloaded by third parties as they are publicly accessible all the time on the relays. So don't consider expiring messages as a security feature for your conversations or other uses."

Replaceable events: overwrite is not deletion either

NIP-01 gives a fourth behaviour that people mistake for deletion. For replaceable kinds (0, 3, and 10000–19999) and addressable kinds (30000–39999), "only the latest event MUST be stored by relays, older versions MAY be discarded." Publishing a new profile hides the old one from honest relays answering normal queries. But MAY discard is not MUST discard, and anyone who fetched the old version still has it, signature intact.

What you can actually check

Deletion literacy comes down to a few habits that travel anywhere:

Look at the relay's NIP-11 document. NIP-11 lets a relay publish supported_nips. If 9, 40 or 62 isn't listed, don't assume the behaviour. Listing it is a claim, not an audit, but absence is informative.
Know where you published. Requests go to relays. If you don't know which relays hold an event, you can't address all of them. Your relay lists, covered in our NIP-65 note, are the starting point.
Assume archives exist. Anyone can run a relay or a crawler that ignores kind 5 and kind 62 entirely. The protocol can't distinguish an archive from a cache.
Treat the signature as permanent. A deleted event that resurfaces still verifies under your key. Deletion withdraws distribution; it never un-signs.

The civil-liberty angle cuts both ways, and both matter worldwide. The same property that lets a journalist's reporting survive a hostile takedown also means a person can't recall a post made in anger, or under a name that later endangers them. Nostr chose censorship resistance, and erasure-resistance comes in the same package. The practical answer is upstream: decide what to sign before you sign it, and keep separate keys for separate risks, as our nsec note explains.

What this is not

This is not legal advice, and it does not say whether any data-protection law applies to any relay or operator. It is not a ranking or endorsement of relays or clients, and it doesn't claim that any named relay honours or ignores these NIPs; check each one's NIP-11 and policies yourself. It isn't an argument against the deletion NIPs, which do useful work among cooperating relays and clients. It isn't a promise that a well-formed kind 62 makes you disappear. And it has nothing to do with tokens, prices, custody or trading. The spec quotes are from the NIPs repository's master branch as of 28 October 2026; all three NIPs are marked draft, so re-read them before you build on them.

The one-line takeaway: on Nostr you can ask to be forgotten, and good relays will listen; you can't make the network forget, so sign as if every event is permanent.