i'm not quite finished the implementation yet but what i have done is add an index that is just a byte flag index type and the hash of the event, and when it goes to save the event it looks for one of these indexes and if it finds it, it returns an "OK",false,"invalid: event was deleted, not saving it again"
Discussion
now i think about it, i think i need to extend that feature to tombstone the replaced ones as well, so they don't get resurreted after deleting the newest version
i also have to account in there for the time of the delete so the tombstones can eventually be pruned off after a substantial time passes (like 6+ months)
oh yes, i also needed to mention that it keeps and will return the kind 5 delete events as well, these also can be removed after a time as part of the garbage collection process
still more things to get right, right now on that project i'm building out a follow/mute list based access control system that makes it really easy to control access to relays without making any new interface
IMO, you can’t safely prune the kind=5 delete events* because your relay could later receive again the event that was supposed to have been deleted.
* unless you know that the previously deleted event had a created_at stamp that’s outside the relay’s retention policy window.
> now i think about it, i think i need to extend that feature to tombstone the replaced ones as well, so they don't get resurreted after deleting the newest version
IMO, it may be correct to resurrect.
If a user makes note A, then replaces it with note B, then deletes note B, they may expect that note A is what gets served.
Suppose user makes A -> B -> C, then deletes B. Presumably that should not impact serving C.
oh btw, if it's replaceable, it is the same event, so, delete one, delete all... replacing deletes the old literal id and deleting the event removes the newest version, you can always make a new one but the old one should not appear from the grave
I understand that position, however I think it depends on how the kind=5 deletion event was specified, and the relay’s policy with regards to storing replaced events.
NIP-09 allows either the ‘e’ tag (specific event id) or the ‘a’ tag (“kind:pubkey:d-identifier”).
If the deletion event specifies a particular event by its id (‘e’ tag), then it’s an open question how to proceed.
Consider these different cases:
## Delete then replace
1. User creates replaceable event A.
2. User deletes replaceable event A with ‘e’ tag specificity.
3. User creates replacement event B.
Expected behavior: REQs receive B.
## Replace then delete original
1. User creates replaceable event A.
2. User creates replacement event B.
3. User deletes replaceable event A with ‘e’ tag specificity.
Expected behavior: REQs receive B.
## Replace, then delete replacement
1. User creates replaceable event A.
2. User creates replacement event B.
3. User deletes replaceable event B with ‘e’ tag specificity.
Expected behavior: ???
IMO, the correct behavior is to serve event A. A is still a valid event. Its replacement was deleted.
An alternative interpretation would be that REQs get nothing since the relay receiving B immediately purged A on the grounds that it was replaced.
To my knowledge, NIP-01 and NIP-09 do not address this specific case. NIP-01 states that “even if the relay has more than one version stored, it SHOULD return just the latest one.” It does not specify what should happen if the latest one was deleted.
NIP-01 continues with “These are just conventions and relay implementations may differ.” I interpret this to mean that the handling of replaced events is a matter of relay policy, especially when incorporating the additional complication of NIP-09 deletes.