NIP-09: clarify "a" tag deletions

[alexgleason]

Deleting a replaceable event is not well defined. It should delete all versions of the event up to the created_at timestamp of the deletion event itself, to allow the author to publish that kind of event in the future.

[staab]

@jb55 @v0l does this pass the sniff test?

[alexgleason]

@fiatjaf You good with this? Asking since you had also opened #1263

[vitorpamplona]

Can we make sure StrFry operates in this way?

[alexgleason]

Can we make sure StrFry operates in this way?

strfry does not support "a" tag deletions: https://github.com/hoytech/strfry/blob/master/src/events.cpp#L332

As much as I love strfry for its ingenuity and efficiency, it should not be regarded as the flagship relay implementation. It has quite a few bugs and is not actively being developed at the pace most of us are moving at.

I don't think I will use strfry for future projects. It's actually not that hard to build a relay - way easier than building a client. Between a 150 line controller and 400 line storage adapter I have a relay that works better than strfry and supports all these features. It's not as efficient with storage but the functionality is better.

[vitorpamplona]

I agree but the reality is that, right now, everyone runs StrFry. It has become the de-facto standard for Nostr. :(

[staab]

Lack of support on the relay side shouldn't block a-tag deletions. Clients that want to support them should be downloading them anyway, so it shouldn't make any real difference in end-user experience.

[alexgleason]

strfry does not even properly support NIP-01 due to mishandling since and until filters. See: hoytech/strfry#110 EDIT: I was wrong about this.

What strfry does should basically not influence what we do with NIPs.

Exactly @staab, was typing this at the same time.

[vitorpamplona]

I just hope this doesn't become yet another NIP-26 that exists only on paper.

[alexgleason]

"a" tag deletion is already in the spec. This is just a clarification of what is already documented, matching what all known implementations are already doing. Whether a-tag deletions are wrong does not really pertain to this MR. If we decide later it is still wrong for some reason, we can remove the original text. But as long as a-tag deletions are in this document, it's helpful to have the clarifying statement.

[AsaiToshiya]

Just to confirm, as explained in NIP-01, basically when a new replaceable event is published, older versions should be deleted, right?

nips/01.md

Lines 96 to 98 in d251ca0

	- for kind `n` such that `10000 <= n < 20000 || n == 0 || n == 3`, events are **replaceable**, which means that, for each combination of `pubkey` and `kind`, only the latest event MUST be stored by relays, older versions MAY be discarded.
	- for kind `n` such that `20000 <= n < 30000`, events are **ephemeral**, which means they are not expected to be stored by relays.
	- for kind `n` such that `30000 <= n < 40000`, events are **parameterized replaceable**, which means that, for each combination of `pubkey`, `kind` and the `d` tag's first value, only the latest event MUST be stored by relays, older versions MAY be discarded.