nips
nips copied to clipboard
nostr-protocol
Right to Vanish
Adds a special event kinds for relays to allow for
- Full deletion of an account to specific relays
- Full deletion of an account to ALL relays
Read here
Starting over from scratch from one point in time onwards is a good feature.
Considering that an user could change their mind by using a kind:5 to delete the kind:62, scoping it to a relay is ok too. Or else user could be just punising themselves by forbidden backing up their old events on that one relay, forever.
@vitorpamplona have you considered merging the two kinds into a single parameterized replaceable event with the d tag set to "" if for all relays or to "<relay-url>" if for a specific relay? It feels like a good fit.
I am against the merge because the second event kind is much more dangerous than the first. Keeping things separate should avoid some mistakes but clients (like forgetting to set the relay or d tag)
Add a switch so that if tags is empty - delete all
if a tag list is included - delete only those tags associated with the pubkey.
Note: I understrand that the additional granularity is outside the "Right to Vanish" scope.
I also like @arthurfranca's idea but instead of "" meaning all, have something like "ALL_RELAYS".
This is a harder mistake to make than using kind 63 instead of 62 and avoids having an extra kind.
CC @jb55 I think you publish some kind of account deletion event in Damus to comply with the Apple rules. Curious what you think of this.
Ok, unified the two kinds in one with the ALL_RELAYS tag as requested.
Ok, unified the two kinds in one with the ALL_RELAYS tag as requested
But it was supposed to be a d tag instead of relay one, a parameterized replaceable event (PRE).
A PRE fits nicely because the proposed event is unique per relay url.
Also, the fact that user events get deleted from the oldest one up until the proposed event's .created_at timestamp, makes it ok to overwrite the timestamp with a newer .created_at value from a PRE replacing an older version of itself.
But it was supposed to be a d tag instead of relay one, a parameterized replaceable event (PRE).
It can't. The event can have more than one target relay.
Relays MAY store the deletion request for bookkeeping and ensure past events are not re-broadcasted into the relay.
If I'm relay "A", references to relays "B", "C", ..., "Z" are bytes I don't want to store.
Contrary to what happens in most other use cases, this one benefits from splitting many references into individual events.
If I'm relay "A", references to relays "B", "C", ..., "Z" are bytes I don't want to store.
If that is the case, you probably also don't want to maintain an entry in the replaceable address index for this event in case the user sends a new one.
Deletion events should not be replaceable.
informs a specific relay to delete everything [...] until its .created_at
An event replacing the older one would effectively extend the "until" period. Isn't it desired?
An event replacing the older one would effectively extend the "until" period. Isn't it desired?
Yes, but we don't need the infrastructure of replaceable events to do that. The regular 62 will delete past 62s as well.
Replaceable events infra is already in place (NIP-01), no extra lines of code for the replacement logic.
Replaceable events infra is already in place (NIP-01), no extra lines of code for the replacement logic.
My point is that we don't need to do replacement + deletion logics. Deletion logic is already enough.
Clients that don't implement replaceable events don't need to implement it.
Though.. a newer d-tag=ALL_RELAYS may replace an older d-tag=my-relay
And there is wss:// vs ws://, also trailing slash or not.
You have a point, the replacement logic can't rely solely on PRE flow.
Deletion logic is already enough.
Got it, if it replaces everything that came before, it replaces older 62. I was wrong.
I don't really believe in a universal "right to vanish" for distributed protocols.
-
Cache invalidation is a very complex problem. Throwing a "delete" event (be it kind 5, or this kind, or others) into the ether gives users a false sense of security. OK, you've said you want to delete some/all events, but do all the relays that store your events implement this NIP? Do they store the deletion request^1 indefinitely so that things don't show up again? Did your message even make it to all the relays where your content was cached? If relays are free to not store deletion requests^1 or not implement this NIP, you don't actually get a full "delete".
-
Single/Mass deletion gives a false sense of security in the case of key compromise. If a user sees a post that they didn't post, and they delete it, they may think they've "dealt with" the issue, when in reality their key is still compromised.
-
It's also an avenue for social abuse. Users can post awful content, then just delete it after the fact to avoid any consequences. Social media is social. If we have a conversation and you say awful things, you shouldn't get to just mind-wipe the internet of your actions.
-
It can also introduce a potential for abuse. If relays DO store deletion events, now users can just fill relays with deletion events which they have to hold forever so that those events don't come back?
All that said, I suppose for those who do want to allow for deletion, or those that have to in order to comply with some laws, it's good to have a standard for this.
Some feedback:
I feel like "Delete Account" is a bad name for this. You're still going to have your pubkey, and all of your followers. And all of your content, on relays that aren't targeted. It's more like "Delete Content Before X From Server Y". And "Right To Vanish" is … just the same thing targeted at all relays. Maybe "Delete Content [From Relay]" and "Reset Account" are better terms for what these two cases accomplish?
If you want a real Delete Your Account, it should be an irrevocable revocation of the pubkey. Something like:
{
"kind": whatever, // new kind # for pubkey revocation?
"pubkey": pubkey,
"content": seckey
}
Advantages:
- There's no coming back from this one. The secret key is out there, so anyone can now impersonate that account.
- The former user of the account gains plausible deniability for any old content. It could've been forged and backdated with their secret key, which is now in the public domain.
- Relay operators will want to store these kinds of revocations and delete other events, because they are possibly inauthentic, since the key is in the public domain.
- Key holders are less likely to abuse this than kind 5/62 deletion events, because the cost is losing their social network and truly starting over again from scratch.
If I was a maintainer, I'd ACK. This'd be neat for GDPR compliance, of sorts, and can easily be advertised by relay documents. 👍
It's a welcome feature.
Given the recent terminology change on nip-09 from "delete" to "deletion request" is any terminology update needed here?
E.g. "right to vanish" -> "request to vanish"
What would deleting a kind:62 event do (via kind:5)? Would it basically allow user to republish their old (backed up) events? Could this be specifically mentioned in the NIP?
Either that or we just don't allow deletions. Deleting kind 62 allows the user to fix potential mistakes, but it also allows an attacker that has access to an nsec to restore everything to its full glory.
I am leaning more towards disallowing kind 62 to be deleted in the same way we don't allow kind:5 to delete other kind 5s
Either that or we just don't allow deletions. Deleting the kind 62 allows the user the fix potential mistakes, but it also allows an attacker to got access to an nsec to restore everything to its full glory.
I am leaning more towards disallowing kind 62 to be deleted in the same way we don't allow kind:5 to delete other kind 5s
Agree with disallowing to delete kind 62. Either one should be probably mentioned in nip to avoid ambiguity
This NIP has been deployed in the latest version of Nos and relay.nos.social.
Unfortunately we didn't make a PR directly to strfry. We instead went with a strfry plugin that pushes kind 62 events to a redis stream where they are processed by all our systems (NIP-05, push notification service, and a script that deletes events from strfry). But it's all open source and we have a docker compose file if anyone wants to copy it.
@vitorpamplona have you added this to Amethyst yet?
@vitorpamplona have you added this to Amethyst yet?
Not yet, but will do soon.
I usually wait for somebody else to code the NIPs I propose to confirm that my idea is not just complete trash. :)
This has the same problem that allowing tagged users to delete events has, which is that it completely breaks all use of shared keys. In #875, all members of a group share a key. This allows anyone to post to the group, but with this PR it would allow all members of the group to delete all the other members' posts. While NIP 87 is likely going away, I also don't think it's the only valid use of a shared pubkey. We should see if the gift-wrap part of this PR can be handled some other way.
This has been deployed to https://relay.netstr.io/ I wrote a few gherkin scenarios for this NIP if anyone interested: https://github.com/bezysoftware/netstr/blob/main/test/Netstr.Tests/NIPs/62.feature