-
Notifications
You must be signed in to change notification settings - Fork 624
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Right to Vanish #1256
base: master
Are you sure you want to change the base?
Right to Vanish #1256
Changes from 14 commits
4d64605
2137719
609571e
651abea
0162794
985388e
86fc593
7521f7a
d9b39fc
ab8a580
59eb1cc
9601eb2
1cf833d
44d8122
4b73e75
553de66
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
NIP-62 | ||
====== | ||
|
||
Request to Vanish | ||
----------------- | ||
|
||
`draft` `optional` | ||
|
||
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. | ||
|
||
## Request to Vanish from Relay | ||
|
||
Kind `62` requests a specific relay to delete everything, including [NIP-09](09.md) Deletion Events, from the `.pubkey` until its `.created_at`. | ||
|
||
```jsonc | ||
{ | ||
"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](59.md) Gift Wraps that p-tagged the `.pubkey`, deleting all DMs to the pubkey. | ||
vitorpamplona marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Relays MUST ensure the deleted events cannot be re-broadcasted into the relay. | ||
|
||
Relays MAY store the signed deletion request for bookkeeping. | ||
|
||
Paid relays or relays that restrict who can post MUST also follow the request regardless of the user's status. | ||
|
||
Kind `5` deletions MUST not delete kind `62`s. | ||
vitorpamplona marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Clients SHOULD send this event to the target relays only. | ||
|
||
## Global Request to Vanish | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. to make sure that only specified relays would do this, isn't it better to use nip-70? im planning to implement it on immortal this way. if you had any reason for not using nip-70, i think we need to add it to spec.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Clients may add that. Relays shouldn't require it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i mean something like this: a relay receives a right to vanish. is it protected? so ask for auth. its not? so execute it. then we don't need to have There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The relays tag exist to avoid client mistakes. Most clients auth automatically. So if they happen to re-broadcast the event to a different relay, they would also auth without even thinking that their actions are changing what the user wanted (deletion in just the previous relay). The meaning of what the author wanted to do should not be dynamic (auth-based). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. makes sense. should a relay black list the user to prevent future incoming events from them as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok. is this defined in spec as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
what about events created after kind 62 that have not been deleted? if we blacklist their pubkey we won't accept them as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do it in a similar way we delete replaceable events: everything up to the deletion event created_at gets blocked but the author can use the key after that date. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. thanks. its already done. |
||
|
||
To request ALL relays to delete everything, the event MUST include a `relay` tag with the value `ALL_RELAYS` in uppercase. | ||
|
||
```jsonc | ||
{ | ||
"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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this mostly called right to be forgotten in the internet. i think we can consider this as a better name. RTBF.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do either. I was reticent to use "forgotten" because deleting stuff from relays doesn't mean you will be "forgotten". It just means that your data was deleted from that instance or instances that received this event and comply to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree and it's logical. but i think this is same for other stuff on web and internet, and using
forgotten
just makes it easier ti understand for people from everywhere. im more agree withforgotten
or maybe something between. we can think more about the name.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
found this: https://en.wikipedia.org/wiki/Right_to_be_forgotten.
they call it vanish as well. we can use one of them and include other one on details of standard. maybe.