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.