NIP-09: Event Deletion Request
A deletion request is honest about distributed memory
NIP-09 exists because users need a way to retract their own events, and relays need a standard signal for that request. In a centralized app, deletion can look like a button that erases one database row. Nostr is not that system. Events can live on many relays, inside client caches, in screenshots, in indexes and in archives the author never saw.
The standard responds with a signed event, kind 5, that points to the event or addressable event the author wants removed. That signed request gives relays and clients something concrete to process. It does not pretend to be stronger than the network model.
That honesty is important for product language. A NIP-09 button ought to mean request deletion, not guarantee disappearance. The official title now says Event Deletion Request, and that wording is the key to teaching it well.
Kind 5, target tags and validation
A deletion request is a kind 5 event. It includes one or more e tags for regular events or a tags for addressable events. The request can include a k tag telling clients and relays the kind of each target event. The content field may contain a human-readable reason.
The client-side validation rule is central. A client has to check that the deletion request comes from the same pubkey as the event being deleted. Otherwise any user could create kind 5 events aimed at other people's notes and a naive client would hide them. For addressable events, the request can delete all versions up to the request timestamp.
Relays that honor the request remove the referenced events and keep publishing the deletion request itself. Keeping the request available is not a contradiction. It is how clients learn that an event was requested for removal and avoid wasting time searching more relays for a missing object.
The standard became more careful as edge cases appeared
The visible file began in the 2022 migration. In June 2023, Pablo Fernandez added support for a tags, which made deletion requests usable for replaceable and addressable events rather than only event IDs. In June 2024, Alex Gleason clarified how a tag deletions work across versions. In July 2024, Jon Staab added the k tag recommendation.
The wording shifted in August 2024 when Terry Yiu renamed the concept to deletion request. That rename matters because GitHub issues had already exposed the user-expectation problem. Issue #343 asked about replacement of deletion reasons. Issue #669 explored tombstones and the problem of relays returning nothing when an event is deleted, leaving clients to hunt elsewhere.
The ongoing debates are healthy. They show that deletion is not one feature. It is relay behavior, client rendering, user expectation, spam policy, archival reality and sometimes legal risk wrapped into one small signed event.
Clients need to show humility at the exact moment users expect certainty
A good implementation sends the kind 5 request to the relays likely to hold the original event, validates authorship before hiding anything, and gives the user a clear result: this request was published; some relays may honor it; copies can remain elsewhere. That is less comforting than a simple deleted label, but it is more honest.
Relays face their own choices. They can delete the original, keep the deletion event, return deletion events when queried for missing targets, or ignore deletion entirely depending on policy. Issue #669 is useful because it explains the tombstone problem: if a client only gets silence from one relay and the original from another, the deleted event can reappear unless deletion signals are discoverable.
NIP-62, Request to Vanish, exists beside this page for broader account-level removal requests. It does not replace NIP-09. It shows that removal in a distributed network has layers: one event, an addressable object, a whole relay scope, maybe all known relays. Each layer needs clearer UI than the word delete usually provides.
Deletion language can overpromise faster than the protocol can deliver
The biggest risk is user deception by accident. If a client says deleted without explaining the distributed context, the user may believe the event is gone everywhere. It may still exist on another relay, in a search index, on a client device or in a third-party archive.
The second risk is malicious hiding. Without strict pubkey validation, a deletion request could become a censorship tool. NIP-09 is useful because it standardizes the signal and tells clients how to treat it carefully. It is not a magic eraser.
Read NIP-09 in the wild
NIP-09 is the deletion request standard, and the word request is doing real work. You can sign an event asking relays and clients to stop serving earlier events. You cannot force every server, scraper, archive or screenshot to forget what it already saw.
That makes the page useful precisely because it refuses to promise magic erasure. A good product shows which events were requested for deletion, which relays acknowledge the request and what may remain elsewhere.
What changes when you actually use it
For you, NIP-09: Event Deletion Request is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms draft, relay, e, a, content, pubkey are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-09: Event Deletion Request is compatibility discipline. Implement draft, relay, e, a, content, pubkey against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
The official file is organized around Client Usage, Relay Usage, Deletion Request of a Deletion Request. Inspect draft, relay, e, a, content, pubkey, created_at because these are the pieces most likely to surface as product behavior.
NIP-09: Event Deletion Request is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-09: Event Deletion Request is often indirect. Nobody complains about draft, relay, e, a, content, pubkey; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-09: Event Deletion Request is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats draft, relay, e, a, content, pubkey as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-09: Event Deletion Request is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-01 and the adjacent source links to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-09: Event Deletion Request does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-09: Event Deletion Request does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-09: Event Deletion Request with the visible product symptom, then trace it back to draft, relay, e, a, content, pubkey. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: Issue #669: better deletions / tombstones, Issue #343: deletion suggestions, NIP-62 Request to Vanish, Nostr.co.uk NIP-09 explainer. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-09 source is the anchor for exact wording, and NIP-09 commit history shows how that wording moved over time. The strongest secondary clues here are Issue #669: better deletions / tombstones, Issue #343: deletion suggestions, NIP-62 Request to Vanish. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-09: Event Deletion Request: first the human promise, then draft, relay, e, a, content, pubkey, then the implementation record, then the real-world failure case. That order keeps NIP-09 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
draft,relay,e,awithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-01 and the adjacent source links, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
draft,relay,e,a,contentin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-09 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-09: Event Deletion Request in that order: Official NIP-09 source for the current wording; NIP-09 commit history for the change record; Issue #669: better deletions / tombstones, Issue #343: deletion suggestions, NIP-62 Request to Vanish for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
