Step 1 of 5
Name the relays
A kind 62 event lists each relay that should forget you in a relay tag. Clients should only send it to those relays.
NIP-62
DraftEventsRelay
A signed request asking relays to permanently delete everything a key has published, either on named relays or everywhere at once.
Edit the form or the JSON: both stay in sync, the badge says whether the result is valid, and tapping any field explains it.
Not signed yet · Demo keys only. These personas' secret keys are public on purpose.
Select any field in the form or the JSON to see what it does.
Step 1 of 5
A kind 62 event lists each relay that should forget you in a relay tag. Clients should only send it to those relays.
NIP-09 deletion asks to remove specific events; vanish removes everything, deletions included.
Relays should also drop gift wraps (DMs) that p-tag the vanishing key.
Relays may require AUTH before accepting the request.
Specification text is quoted in English from the nostr-protocol/nips repository. Our explanations and the interface are translated. Source on GitHub at commit 0046368
This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database.
Kind 62 requests a specific relay to delete everything, including NIP-09 Deletion Events, from the .pubkey until its .created_at.
{
"kind": 62,
"pubkey": <32-byte hex-encoded public key of the event creator>,
"tags": [
["relay", "<relay url>"]
],
"content": "<reason or note>",
//...other fields
}
The tag list MUST include at least one relay value.
Content MAY include a reason or a legal notice to the relay operator.
Relays MUST fully delete any events from the .pubkey if their service URL is tagged in the event.
Relays SHOULD delete all NIP-59 Gift Wraps that p-tagged the .pubkey if their service URL is tagged in the event, deleting all DMs to the pubkey.
Relays MUST ensure the deleted events cannot be re-broadcasted into the relay.
Relays MAY store the signed request to vanish for bookkeeping.
Paid relays or relays that restrict who can post MUST also follow the request to vanish regardless of the user's status.
Publishing a deletion request event (Kind 5) against a request to vanish has no effect. Clients and relays are not obliged to support "unrequest vanish" functionality.
Clients SHOULD send this event to the target relays only.
To request ALL relays to delete everything, the event MUST include a relay tag with the value ALL_RELAYS in uppercase.
{
"kind": 62,
"pubkey": <32-byte hex-encoded public key of the event creator>,
"tags": [
["relay", "ALL_RELAYS"]
],
"content": "<reason>",
//...other fields
}
Clients SHOULD broadcast this event to as many relays as possible.