diff options
| author | Semisol <45574030+Semisol@users.noreply.github.com> | 2023-04-16 00:25:53 +0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-04-16 00:25:53 +0300 |
| commit | a8e083d6d8e1fa0176bc5cfe96427ac37e4d6046 (patch) | |
| tree | 3000ca8ab3b037e8a7f22185f3ffeaf27a50b775 | |
| parent | 7c8c2eeffa91d4a527c8c1db670d22c9a1f745e2 (diff) | |
NIP-09: Fix some things
| -rw-r--r-- | 09.md | 4 |
1 files changed, 2 insertions, 2 deletions
| @@ -27,13 +27,13 @@ For example: | |||
| 27 | } | 27 | } |
| 28 | ``` | 28 | ``` |
| 29 | 29 | ||
| 30 | Relays SHOULD delete or stop publishing any referenced events that have an identical `id` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. | 30 | Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events. |
| 31 | 31 | ||
| 32 | Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it. | 32 | Relays SHOULD continue to publish/share the deletion events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion events to other relays which don't have it. |
| 33 | 33 | ||
| 34 | ## Client Usage | 34 | ## Client Usage |
| 35 | 35 | ||
| 36 | Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted event's own content, although a user interface should clearly indicate that this is a deletion reason, not the original content. | 36 | Clients MAY choose to fully hide any events that are referenced by valid deletion events. This includes text notes, direct messages, or other yet-to-be defined event kinds. Alternatively, they MAY show the event along with an icon or other indication that the author has "disowned" the event. The `content` field MAY also be used to replace the deleted events' own content, although a user interface should clearly indicate that this is a deletion reason, not the original content. |
| 37 | 37 | ||
| 38 | A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. | 38 | A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. |
| 39 | 39 | ||