Update NIP-09 to rename to deletion request

[tyiu]

There's endless debates about whether or not Nostr supports deletion, but I think the confusion stems from overloading the term "delete". In actuality, Nostr supports "request for deletion", but it's a mouthful and can still be confused with just plain "deletion".

Let's call it "retraction" when we mean a request for deletion, and reserve "deletion" when we actually mean delete.

[tyiu]

Tagging in @rabble as I know he's vocal about supporting request for deletion. But would love more feedback from others.

[alexgleason]

This language makes sense for clients, but not relays. I think it should remain clear to relay implementers that they should delete the data. So I think you should call it "Retract" in the UI, but the NIP should still say delete.

EDIT:

reserve "deletion" when we actually mean delete.

Is there a use-case I'm missing?

[tyiu]

This language makes sense for clients, but not relays. I think it should remain clear to relay implementers that they should delete the data. So I think you should call it "Retract" in the UI, but the NIP should still say delete.

EDIT:

reserve "deletion" when we actually mean delete.

Is there a use-case I'm missing?

The use case is sort of what you're saying already. Use "delete" as a verb when we mean physically deleting the data from a client or relay. Use "retract" when it's creating and publishing the kind 5 to describe the user's intent.

[tyiu]

This language makes sense for clients, but not relays. I think it should remain clear to relay implementers that they should delete the data. So I think you should call it "Retract" in the UI, but the NIP should still say delete.

I'm not sure I agree. Even on relays, they don't have to delete the data. They could store the retraction event and not adhere to it. In that case, it's still a retraction event, because it describes the user's intent to retract their data. Not to be confused with the fact that it's an indicator that what it's referencing has been deleted.

[alexgleason]

I think your argument is true, but I think it makes the NIPs more complicated. Somebody should be able to look at the README and see the words "Follow List" instead of "Contacts List", "Deletion" instead of "Retraction", etc.

I would do something more subtle. Put a note at the top, or a section inside, arguing that deletion is actually more like a retraction, encouraging clients to use the term "Retraction" and to provide a disclaimer to users about guarantees.

[tyiu]

I think your argument is true, but I think it makes the NIPs more complicated. Somebody should be able to look at the README and see the words "Follow List" instead of "Contacts List", "Deletion" instead of "Retraction", etc.

I would do something more subtle. Put a note at the top, or a section inside, arguing that deletion is actually more like a retraction, encouraging clients to use the term "Retraction" and to provide a disclaimer to users about guarantees.

I understand your concern about quick discoverability of specs for the uninitiated developer. I worry that it's too subtle. I'll use myself as an example. Even though I was fully aware of the deletion NIP and the limits of how deletions work, I still somehow subconsciously used the term "delete" in variable names in code, and in user-facing strings. Nostr SDK for Apple Platforms follows the naming conventions defined in the NIPs repo, and therefore we have a class called DeletionEvent. In Comingle, I use the SDK to create DeletionEvents, so it felt natural to call it deletion everywhere, even though that's not what it does. All of that terminology is signaling something different.

I feel like a motivated developer who wants to support deletion would be able to scan through and figure out that retraction is what they want, but I'm not 100% sure. Another alternative could be putting (Request for Deletion) in parentheses in the NIP title after Event Retraction, though it feels verbose.

[mikedilger]

NIP-09 events are requests for removal of the original note.

I think of a retraction as an explanation, rather than a removal request, e.g. "I hereby retract the above note because I was mistaken about XYZ".

I gather that you think of a deletion as a deletion and not a deletion request.

Maybe we would both be happy with "deletion request" rather than "delete" or "retraction".

[alexgleason]

I am fine with Deletion Request

[alexgleason]

@tyiu In my code, kind 5 events actually do delete things: https://gitlab.com/soapbox-pub/nostrify/-/blob/main/packages/db/NPostgres.ts?ref_type=heads#L112

The kind 5 causes a DELETE FROM nostr_events query to be sent to my database, which then deletes the row(s).

[mikedilger]

Chorus actually deletes (the event is blanked, the indexes are tombstoned)

Gossip renders with strikethrough, but I'm of two minds about it... nobody has filed a bug against this yet.

[tyiu]

NIP-09 events are requests for removal of the original note.

I think of a retraction as an explanation, rather than a removal request, e.g. "I hereby retract the above note because I was mistaken about XYZ".

I gather that you think of a deletion as a deletion and not a deletion request.

Maybe we would both be happy with "deletion request" rather than "delete" or "retraction".

I can live with "deletion request". It's strictly better than "delete". I'll update the PR.

[tyiu]

@tyiu In my code, kind 5 events actually do delete things: https://gitlab.com/soapbox-pub/nostrify/-/blob/main/packages/db/NPostgres.ts?ref_type=heads#L112

The kind 5 causes a DELETE FROM nostr_events query to be sent to my database, which then deletes the row(s).

Glad to hear it! I'm supportive of the NIP, and I'm also supportive of giving choice to those who do not want to implement it (or use software that do not implement it).

[tyiu]

Updated.

[mattn]

BTW, we need to add NIP-11 identification number that the relay supports deletion?

[fiatjaf]

BTW, we need to add NIP-11 identification number that the relay supports deletion?

I think we should.

[alltheseas]

@setch-l verbiage change consideration for yall