NIP-62: Request to Vanish
Deletion requests are not enough for a full reset
NIP-09 lets an author request deletion of specific events. NIP-62 is broader. It asks a relay to delete everything from a pubkey up to the request timestamp, including deletion events themselves and relevant NIP-59 gift wraps.
The source is explicit that this can be legally binding in some jurisdictions. That gives the NIP a different tone from ordinary protocol convenience. It is about a key asking for a complete reset of its web fingerprint.
The careful wording is request. A signed event can instruct supporting relays. It cannot force every relay, archive, scraper, screenshot or peer to erase data. The standard gives compliant relays a native signal and users a consistent tool.
Targeted relay vanish and ALL_RELAYS vanish
Kind 62 carries the request. For a targeted vanish, the event includes one or more relay tags naming relay URLs. Relays whose service URL is tagged must delete events from that pubkey and ensure they cannot be rebroadcast into the relay. They may keep the signed request for bookkeeping.
For a global request, the relay tag value is ALL_RELAYS. Clients need to broadcast that request to as many relays as possible. Paid relays or restricted relays are still expected to follow the request regardless of the user's current access status.
The NIP also says deletion requests against the vanish request have no effect. There is no required unrequest-vanish function. That is harsh, but it prevents a reset request from being casually undone by another event.
A right-to-vanish proposal with relay implementation questions
Vitor Pamplona added the visible Right to Vanish work in February 2025. Later repo-wide cleanup touched relay tags and markdown formatting. The short history fits the NIP's shape: one event kind, one strong instruction, many operational questions.
Relay implementation trackers tell the real story. nostr-rs-relay and strfry issue threads discuss support for NIP-62, and nostrability tracks positive interoperability. The standard is only meaningful if relays actually change storage behavior.
That makes NIP-62 one of the pages where Crays needs to be especially precise. It is not magic deletion. It is a compliance and relay-operations signal.
The relay has to prevent resurrection
Deleting old events is only half the job. NIP-62 says relays must ensure deleted events cannot be rebroadcast into the relay. That means a relay needs a tombstone or blocklist strategy keyed to the vanish request, even if it removes the original event bodies.
Clients need to send targeted requests only to the target relays. For ALL_RELAYS, they needs to broadcast widely. They needs to also explain that other relays, archives and third parties may not comply.
A good relay admin interface needs to show the signed request, target pubkey, cutoff timestamp, affected event counts, gift-wrap handling and rebroadcast prevention status.
You need the truth about deletion
The main risk is overpromising. A relay can delete its own database. It cannot delete screenshots, cached clients, other relays or data already copied by third parties.
There is also operational risk. If relays keep no bookkeeping, old events may be reintroduced. If they keep too much bookkeeping, they may preserve sensitive metadata. NIP-62 leaves hard tradeoffs to operators.
Read NIP-62 in the wild
NIP-62 gives people a request-to-vanish signal. It is an important human feature because real users need exits, corrections and ways to ask responsible services to stop serving old material.
It is not a memory hole. Nostr replication means copies can remain. The honest product says what was requested, who may honor it and what cannot be guaranteed.
What changes when you actually use it
For you, NIP-62: Request to Vanish is felt when someone makes a claim about content, people, trust, status or community behavior. Reports, labels, badges, assertions and polls can help you navigate an open network, but they can also become quiet authority. Read NIP-09, NIP-59 so you see who speaks, what is targeted and how much weight the claim deserves.
What changes for builders and operators
For builders and moderators, NIP-62: Request to Vanish means preventing claims from becoming invisible law. Show issuer, target, reason, timestamp, evidence and conflict. Let people understand why a label, report, badge or assertion appears before it changes what they can see.
What the official file makes concrete
The official file is organized around Request to Vanish from Relay, Global Request to Vanish. Inspect draft, relay, .pubkey, .created_at, ALL_RELAYS because these are the pieces most likely to surface as product behavior. Read it beside NIP-09, NIP-59 before treating it as isolated.
NIP-62: Request to Vanish is a claim layer. Reports, labels, badges, assertions and polls only help when issuer, target and scope stay visible.
Where it breaks
The failure mode in NIP-62: Request to Vanish is authority theater. A report, label, badge, assertion or poll can look official because it is signed and rendered cleanly. The signature proves the issuer, not the fairness or accuracy of the claim.
Where this appears outside the markdown
In the ecosystem, NIP-62: Request to Vanish belongs to the social safety and coordination layer. It can help people filter noise, recognize contribution, report abuse, run polls or make assertions. It can also concentrate influence quietly if the issuer disappears behind the label. The hub has to preserve that tension instead of selling governance as solved.
The nearby-standard trap
The nearby-standard trap in NIP-62: Request to Vanish is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-09, NIP-59 and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-62: Request to Vanish names the claimant. It says who reported, labeled, awarded, asserted, voted or counted, and it leaves room for conflict. That is how a safety feature avoids becoming invisible authority.
What this page does not promise
NIP-62: Request to Vanish does not make a community decision neutral. Signed reports, labels, badges, assertions and polls can improve safety or discovery, but they still come from people, services or institutions with incentives. The standard helps expose the claim. It does not make the claim fair, complete or universally binding.
Read it as a field test
Start NIP-62: Request to Vanish with the claimant. A label, report, badge, assertion or poll has meaning only when issuer, target, reason and consequence remain visible. The article needs to preserve that social context because signed data can still be biased, stale or disputed.
Where the standard earns trust
The source links give you places to test the interpretation in public: strfry NIP-62 issue, nostr-rs-relay NIP-62 issue, nostrability tracker, NIP-09 Event Deletion. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-62 source is the anchor for exact wording, and NIP-62 commit history shows how that wording moved over time. The strongest secondary clues here are strfry NIP-62 issue, nostr-rs-relay NIP-62 issue, nostrability tracker. 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-62: Request to Vanish: first the human promise, then draft, relay, .pubkey, .created_at, ALL_RELAYS, then the implementation record, then the real-world failure case. That order keeps NIP-62 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who issued the claim, label, badge, report, assertion or poll, and what exactly is the target?
- Can you see evidence, conflicts, expiry and scope before the claim changes what you see?
- Does the design leave room for disagreement instead of hiding authority behind a clean badge?
What to verify before you rely on it
- Find
draft,relay,.pubkey,.created_at,ALL_RELAYSin the official file and check where the UI exposes the same concept. - Read NIP-09, NIP-59 as context before treating NIP-62 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-62: Request to Vanish in that order: Official NIP-62 source for the current wording; NIP-62 commit history for the change record; strfry NIP-62 issue, nostr-rs-relay NIP-62 issue, nostrability tracker 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.
