Add NIP66 draft - Decimate

[hendore]

This NIP paves the way for more control over a users data with the possibility of event management clients appearing to migrate / cleanup old events when switching to new preferred relays.

There are some considerations to take into account which is open for ideas. This may also be too dangerous to roll out until more users understand how to use delegated event signing. My biggest concern is a rouge client deleting all of a users events from all of their preferred relays. This concern is a current vulnerability with the current delete event kind, a bad client could receive all common events (0, 1, 4, 10002, etc...) and send a delete event with those ids tagged to many relays.

If anything comes out of this, maybe it's an educational push to get users creating client specific keys without the ability to delete anything 🤔

[dskvr]

NIP-66 is already taken #230

[hendore]

@dskvr No problem, I can change this one, it wasn't clear what nips ids have been reserved so I just went with the next value after the last merged NIP. Is there a method for finding the next nip id that hasn't been reserved yet?

[barkyq]

Some concerns/questions:

1. When would someone want to use this? One can just send a kind:5 with a bunch of e tags. Seems to cover most use cases. Kind of goes against the NIP-design principle that there should not be multiple ways to achieve the same outcome. This is I think the main problem with this proposal... One difference though is that it is on a per-relay basis (that cannot be achieved with kind:5).
2. Agreed with @Semisol that it should only delete events before created_at. Otherwise there is a replay attack if some malicious user somehow gets a hold of the event (i.e., if they make a REQ for all kind:10 events). Would not even require a "rogue client."
3. If this is supposed to be on a per-relay basis, maybe makes more sense as a command, e.g., ["DELETE", <filter>], used with NIP-42 (similar to REQ, but forcing the filters to have a single author equal to the NIP-42 authorized user).
4. Relays often do not know what their URL is, especially at the database level (i.e., the SQL database probably doesn't know the URL). Complicates the logic of checking whether or not to delete the events. To implement NIP-42, the relay URL needs to be passed to the software somehow. This offers support for why I think this could fit nicely with NIP-42 as outlined in 3.
5. What should a client do if it receives one of these events? Is it supposed to track which relay each event came from?
6. Also think this (and indeed kind:5) should be ephemeral, but that is just my own personal bias.

[hendore]

@barkyq

1. When would someone want to use this? One can just send a kind:5 with a bunch of e tags. Seems to cover most use cases. Kind of goes against the NIP-design principle that there should not be multiple ways to achieve the same outcome. This is I think the main problem with this proposal... One difference though is that it is on a per-relay basis (that cannot be achieved with kind:5).

I did wonder whether this was close to the existing Delete event however however there a few differences, targeting a single relay is one but also most relay software have limits on things such as max tags / request size so if attempting to remove a lot of data (after a long period of usage) from an old relay you no longer want holding your data then it may hit those limits.

2. Agreed with @Semisol that it should only delete events before created_at. Otherwise there is a replay attack if some malicious user somehow gets a hold of the event (i.e., if they make a REQ for all kind:10 events). Would not even require a "rogue client."

Totally agree, 100% (though I think providing a from and until filter could also be useful, so long as until is not greater than the events created_at timestamp)

3. If this is supposed to be on a per-relay basis, maybe makes more sense as a command, e.g., ["DELETE", <filter>], used with NIP-42 (similar to REQ, but forcing the filters to have a single author equal to the NIP-42 authorized user).

That's a very good suggestion, I think it makes much more sense to be a command now you have suggested it.

4. Relays often do not know what their URL is, especially at the database level (i.e., the SQL database probably doesn't know the URL). Complicates the logic of checking whether or not to delete the events. To implement NIP-42, the relay URL needs to be passed to the software somehow. This offers support for why I think this could fit nicely with NIP-42 as outlined in 3.

👍 Brilliant, couldn't agree more.

5. What should a client do if it receives one of these events? Is it supposed to track which relay each event came from?

If we introduce a delete command rather than event then I'm assuming relays wouldn't broadcast the deletion to clients. Clients that have already fetched and cached events that have since been deleted don't need to do anything.

6. Also think this (and indeed kind:5) should be ephemeral, but that is just my own personal bias.

Makes sense.

To be honest, after the feedback so far I'm actually doubting if this is a good idea myself now, the idea was more around migrating my own data from one relay to another, we can re-publish events to a new relay and then it was a tidy up operation to delete those events from the old relay you no longer write to, the events still exist elsewhere but you no longer want a certain relay to provide them but now that feels like it shouldn't matter if another relay still has those events.

[hendore]

I think I'll leave it open for another 24/48 hours, see if any other thoughts on this come in but I'm leaning more toward just closing this proposal now that I've thought about it more and heard feedback.

[barkyq]

I think it is a reasonable proposal nonetheless. It is my self-imposed volunteer duty to come up with whatever criticisms I can, as you can determine by looking at some of my other comments.

[hendore]

@barkyq I wouldn't want it any other way 🤘🏼

[dskvr]

@hendore

Is there a method for finding the next nip id that hasn't been reserved yet?

It's basically the wild west for now, I had to do the same thing as you, just trying to not have to do it over and over again :)

[staab]

My two cents is NACK, this seems like a good niche for another client app to fill. A new special-purpose client can handle the complexity and edge cases better than a new NIP that will have spotty support across implementations.

[barkyq]

My two cents is NACK, this seems like a good niche for another client app to fill. A new special-purpose client can handle the complexity and edge cases better than a new NIP that will have spotty support across implementations.

The one thing I think this proposal brings is a per-relay deletion method (right now, deletion events apply to any relay and client which receives them). Perhaps this use case is too niche though.

---

On further thought, here are some potential use cases:

1. User sets up a private relay just for kind:4 messages, and wants to delete the old kind:4 from other public relays (but still keep the messages). Using kind:5 would be problematic since those events could (perhaps) be replayed to the private relay.

2. Relay X pays user Y to write a daily post to their paid relay, and part of the contract is that the daily post should not be republished to other relays (very non-nostric). Some sort of DELETE command would at least give the user Y some method to remove their post from other relays.

Perhaps some other use-cases. What do y'all think?

The dedicated deletion client @staab considered could use such a delete command in conjunction with the current kind:5 events, for instance.

[staab]

The one thing I think this proposal brings is a per-relay deletion method (right now, deletion events apply to any relay and client which receives them). Perhaps this use case is too niche though.

That's a good point, now that I re-read the NIP for deletions. Maybe a simple solution would be to allow kind 7 to specify policy. Specifying whether to propagate the deletion, and whether the deletion should be ephemeral would probably be enough.

At any rate, deletes are never more than a polite request, so it seems like the use cases above rely too heavily on relay cooperation. Use case #1 above could be accomplished simply by instructing the private relay to ignore deletions. #2 is impossible assuming we're talking about valuable licensed content, piracy on nostr is just going to be a thing.

[barkyq]

@staab yes very good points. ephemeral related to #236