Right to Vanish

[vitorpamplona]

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

[fiatjaf]

@rabble @arthurfranca @mplorentz

[arthurfranca]

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.

[vitorpamplona]

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)

[RandyMcMillan]

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.

[sant0s12]

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.

[mplorentz]

This is nice! Required, I think, for relays in the EU that want to be GDPR compliant. Also the Apple App Store has a rule that you must offer the user a way to delete their account, and this seems like a best-effort way to adhere to that rule, given that you can't force other people to delete your data.

[mplorentz]

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.

[vitorpamplona]

Ok, unified the two kinds in one with the ALL_RELAYS tag as requested.

[arthurfranca]

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.

[vitorpamplona]

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.

[arthurfranca]

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.

[vitorpamplona]

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.

[arthurfranca]

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?

[vitorpamplona]

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.

[arthurfranca]

Replaceable events infra is already in place (NIP-01), no extra lines of code for the replacement logic.

[vitorpamplona]

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.

[arthurfranca]

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.

[arthurfranca]

Deletion logic is already enough.

Got it, if it replaces everything that came before, it replaces older 62. I was wrong.

[NfNitLoop]

I don't really believe in a universal "right to vanish" for distributed protocols.

1. 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¹ 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¹ or not implement this NIP, you don't actually get a full "delete".

2. 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.

3. 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.

4. 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:

1. There's no coming back from this one. The secret key is out there, so anyone can now impersonate that account.
2. 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.
3. 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.
4. 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.

Footnotes

1. re: "Relays MAY store the deletion request for bookkeeping and ensure past events are not re-broadcasted into the relay." ↩ ↩²

[bezysoftware]

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?

[vitorpamplona]

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

[bezysoftware]

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

[mplorentz]

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?

[alexgleason]

I think this is needed and the framing of it is right.

[vitorpamplona]

@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. :)

[staab]

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.

[bezysoftware]

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

[staab]

it completely breaks all use of shared keys

Never mind, shared keys are already broken. What we need to fix it is a mechanism to say events can't be deleted by the author, or the recipient. I rescind my objection.

[kehiy]

i think it can be replaced by #1509 since it would support deletion for all events as well. to specify relays we already have nip-70 and "-" tag which relays can interpret. adding new rules to do the same thing is unnecessary complexity imho.

[staab]

I support this, similar to #377 though it should probably allow users to specify all past data, or a complete burn of their key.

[kehiy]

@staab if you mean filter deletion, for relays who keep the filters, they can do the same thing as both nip 109 and 62.

without adding 2 more nip and a lot of complexity.

just send a nip-9 filter deletion with since and unitl set to minimum and maximum possible numbers. it would prevent future events to be written.

we may support freezing an account for a while using same model.

in relay side we would have different ways to support it.

here is an article explaining it:

https://njump.me/naddr1qq2nyv3ndf342d6ewcm52dny2d2rvc26w4452qg4waehxw309a4x2mrv09nxjumg9ekxzmny9upzpwkmmkjsw4et89u9ypyw5a8jauadj2c64sru848pmmqhf6xde932qvzqqqr4guth8yy5

ill update the article and add the freeze and delete account details (possible ways of implementation for both clients and relays) to it soon.

also you can find example implementation of immortal: https://github.com/dezh-tech/immortal

[staab]

@kehiy I think the filter version is actually much more complex (it leaks metadata about deleted events, how is "search" interpreted, it's not easily indexable, it's going to be more computationally intensive for relays to implement), and isn't really justified by use case. The way I see it, we need the following types of deletes:

• Delete this event. Bulk deletes are weird, if you published a bunch of events, just tag each one. It's still much lighter than the original payloads were. With one exception...
• Delete everything on my pubkey until now. A "delete account" option. If this event uses the expiration tag, you could even (optionally) allow re-publishing old events after the delete expires.
• Burn this pubkey. A permanent "delete account" option, for when a key is compromised.

[Semisol]

There must be a "proof of freshness", to prevent dating events to in the future, and soft-bricking the npub.
A public key should not be able to be irreparably damaged due to a malicious or defective client (outside of full compromise of the nsec).

[staab]

soft-bricking the npub

I think this is actually a desirable feature. I agree that it would suck to do this accidentally, but it's probably better to have it.

[kehiy]

@kehiy I think the filter version is actually much more complex (it leaks metadata about deleted events, how is "search" interpreted, it's not easily indexable, it's going to be more computationally intensive for relays to implement), and isn't really justified by use case. The way I see it, we need the following types of deletes:

• Delete this event. Bulk deletes are weird, if you published a bunch of events, just tag each one. It's still much lighter than the original payloads were. With one exception...
• Delete everything on my pubkey until now. A "delete account" option. If this event uses the expiration tag, you could even (optionally) allow re-publishing old events after the delete expires.
• Burn this pubkey. A permanent "delete account" option, for when a key is compromised.

i dont think if it's too complex. you can look at my implementation on immortal which currently performs the deletion of current events well. soon ill support keeping the deleted filter as well. i believe both of them at the same time won't be too complex. about performance, im using a mongo db with multiple database calls and it still performs well. soon ill refactor it to make on call and do the whole deletion which is much more efficient. and it would support all three cases you mentioned and more.

this article explains this filter tag better and answers your question about search and other fields on deletion filter:

https://njump.me/nostr:naddr1qq2nyv3ndf342d6ewcm52dny2d2rvc26w4452qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7q3qhtdamfg82u4nj7zjqj82wnew7wke9vd2cp7r6nsaast5arxujc4qxpqqqp65wvdt5af

[Semisol]

I find it hard to see how relays will honor a feature that can be abused to hold anyone's npub by ransom just because your web client was able to sign an event. Most people blindly allow apps to sign all kinds of events, and most extensions don't even offer a per-kind option.

[kehiy]

There must be a "proof of freshness", to prevent dating events to in the future, and soft-bricking the npub. A public key should not be able to be irreparably damaged due to a malicious or defective client (outside of full compromise of the nsec).

one of good approaches for this is @fiatjaf's idea which was using relay contact and asking them for a change. if someone accidentally freezed, deleted, limited their public-key.

the main idea was asking the relay operator for account deletion itself from fiatjaf on nsf meeting. but this would work for denial of a deletion or freeze. for deletion itself i like the filter model.

[Semisol]

Asking relay operators to undo it doesn't scale though.

[kehiy]

I find it hard to see how relays will honor a feature that can be abused to hold anyone's npub by ransom just because your web client was able to sign an event. Most people blindly allow apps to sign all kinds of events, and most extensions don't even offer a per-kind option.

if you mean in case of filter deletion, relay can set a min pow for deletion request or ask for payments. to prevent huge checks and resources usage.

[kehiy]

Asking relay operators to undo it doesn't scale though.

i agree.

[Semisol]

if you mean in case of filter deletion, relay can set a min pow for deletion request or ask for payments. to prevent huge checks and resources usage.

I think you misunderstood, I was referring to a malicious web client signing a delete everything event on behalf on someone that is dated to in the future, and holding their identity for ransom. Most people allow apps to sign any event kind.

[vitorpamplona]

I was referring to a malicious web client signing a delete everything event on behalf of someone that is dated to in the future, and holding their identity for ransom

I am not sure how proof of freshness solves this. If there is such a client, they can do the same with the past events. They can sign and wait to use in the future as well. The same client can start posting stuff the user didn't approve. If the issue is ransom from a malicious client and that client has the key, I don't think there is anything we can do to protect the user. They can literally do whatever they want with the account.

[kehiy]

@Semisol if your signer/client publishs unexpected deletions on your behalf, then it would do more as well.

check the code, use a safe signer, restrict writing levels to be safe from this. we already have people who loose their follow lists. ive got my profile cleaned multiple time juts because some old web clients considered my old pubkey kind 0 as their base to create new one.