diff options
| author | Terry Yiu <963907+tyiu@users.noreply.github.com> | 2024-08-14 20:02:13 -0400 |
|---|---|---|
| committer | Terry Yiu <963907+tyiu@users.noreply.github.com> | 2024-08-14 20:08:41 -0400 |
| commit | 95885afe2da245b0c4d80b91e9e44ee7f5ad447f (patch) | |
| tree | 5db11cf600c38c9c23e87e4b2ecaddf8afdfad14 | |
| parent | 645a562a8b870a41fd953a422e171b33f74aef07 (diff) | |
Update NIP-09 to rename deletion to retraction
| -rw-r--r-- | 09.md | 26 | ||||
| -rw-r--r-- | 32.md | 2 | ||||
| -rw-r--r-- | 34.md | 2 | ||||
| -rw-r--r-- | 71.md | 2 | ||||
| -rw-r--r-- | 72.md | 2 | ||||
| -rw-r--r-- | 90.md | 2 | ||||
| -rw-r--r-- | README.md | 4 |
7 files changed, 21 insertions, 19 deletions
| @@ -1,14 +1,14 @@ | |||
| 1 | NIP-09 | 1 | NIP-09 |
| 2 | ====== | 2 | ====== |
| 3 | 3 | ||
| 4 | Event Deletion | 4 | Event Retraction |
| 5 | -------------- | 5 | -------------- |
| 6 | 6 | ||
| 7 | `draft` `optional` | 7 | `draft` `optional` |
| 8 | 8 | ||
| 9 | A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being deleted. | 9 | A special event with kind `5`, meaning "retraction" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be retracted. Retraction requests SHOULD include a `k` tag for the kind of each event being retracted. |
| 10 | 10 | ||
| 11 | The event's `content` field MAY contain a text note describing the reason for the deletion. | 11 | The event's `content` field MAY contain a text note describing the reason for the retraction. |
| 12 | 12 | ||
| 13 | For example: | 13 | For example: |
| 14 | 14 | ||
| @@ -28,24 +28,26 @@ For example: | |||
| 28 | } | 28 | } |
| 29 | ``` | 29 | ``` |
| 30 | 30 | ||
| 31 | 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 | Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the retraction request. Clients SHOULD hide or otherwise indicate a retraction status for referenced events. |
| 32 | 32 | ||
| 33 | 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 | Relays SHOULD continue to publish/share the retraction events indefinitely, as clients may already have the event that's intended to be retracted. Additionally, clients SHOULD broadcast retraction events to other relays which don't have it. |
| 34 | 34 | ||
| 35 | When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion event. | 35 | When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the retraction event. |
| 36 | 36 | ||
| 37 | ## Client Usage | 37 | ## Client Usage |
| 38 | 38 | ||
| 39 | 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. | 39 | Clients MAY choose to fully hide any events that are referenced by valid retraction 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 retracted events' own content, although a user interface should clearly indicate that this is a retraction reason, not the original content. |
| 40 | 40 | ||
| 41 | 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. | 41 | A client MUST validate that each event `pubkey` referenced in the `e` tag of the retraction request is identical to the retraction request `pubkey`, before hiding or deleting any event. Relays can not, in general, perform this validation and should not be treated as authoritative. |
| 42 | 42 | ||
| 43 | Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice. | 43 | Clients display the retraction event itself in any way they choose, e.g., not at all, or with a prominent notice. |
| 44 | |||
| 45 | Clients MAY choose to inform the user that their request for retraction does not guarantee deletion because it is impossible to delete events from all relays and clients. | ||
| 44 | 46 | ||
| 45 | ## Relay Usage | 47 | ## Relay Usage |
| 46 | 48 | ||
| 47 | Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself, however this is not required since relays may not have knowledge of all referenced events. | 49 | Relays MAY validate that a retraction event only references events that have the same `pubkey` as the retraction itself, however this is not required since relays may not have knowledge of all referenced events. |
| 48 | 50 | ||
| 49 | ## Deleting a Deletion | 51 | ## Retracting a Retraction |
| 50 | 52 | ||
| 51 | Publishing a deletion event against a deletion has no effect. Clients and relays are not obliged to support "undelete" functionality. | 53 | Publishing a retraction event against a retraction has no effect. Clients and relays are not obliged to support "unretract" functionality. |
| @@ -145,7 +145,7 @@ Author is labeling their note language as English using ISO-639-1. | |||
| 145 | Other Notes | 145 | Other Notes |
| 146 | ----------- | 146 | ----------- |
| 147 | 147 | ||
| 148 | When using this NIP to bulk-label many targets at once, events may be deleted and a replacement | 148 | When using this NIP to bulk-label many targets at once, events may be retracted using [NIP-09](09.md) and a replacement |
| 149 | may be published. We have opted not to use parameterizable/replaceable events for this due to the | 149 | may be published. We have opted not to use parameterizable/replaceable events for this due to the |
| 150 | complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying, | 150 | complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying, |
| 151 | publishers SHOULD limit labeling events to a single namespace. | 151 | publishers SHOULD limit labeling events to a single namespace. |
| @@ -53,7 +53,7 @@ An optional source of truth for the state of branches and tags in a repository. | |||
| 53 | 53 | ||
| 54 | The `refs` tag may appear multiple times, or none. | 54 | The `refs` tag may appear multiple times, or none. |
| 55 | 55 | ||
| 56 | If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion. | 56 | If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) retraction. |
| 57 | 57 | ||
| 58 | The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is: | 58 | The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is: |
| 59 | 59 | ||
| @@ -6,7 +6,7 @@ Video Events | |||
| 6 | 6 | ||
| 7 | `draft` `optional` | 7 | `draft` `optional` |
| 8 | 8 | ||
| 9 | This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and deletable per [NIP-09](09.md). | 9 | This specification defines video events representing a dedicated post of externally hosted content. These video events are _parameterized replaceable_ and retractable per [NIP-09](09.md). |
| 10 | 10 | ||
| 11 | Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience. | 11 | Unlike a `kind 1` event with a video attached, Video Events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTube, or TikTok like nostr client where the video itself is at the center of the experience. |
| 12 | 12 | ||
| @@ -62,7 +62,7 @@ An approval event MUST include one or more community `a` tags, an `e` or `a` tag | |||
| 62 | 62 | ||
| 63 | The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind. | 63 | The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind. |
| 64 | 64 | ||
| 65 | Moderators MAY delete their approval of a post at any time using NIP 09 event deletions. | 65 | Moderators MAY retract their approval of a post at any time using NIP 09 event retractions. |
| 66 | 66 | ||
| 67 | ```jsonc | 67 | ```jsonc |
| 68 | { | 68 | { |
| @@ -199,7 +199,7 @@ Some service providers might choose to submit a `payment-required` as the first | |||
| 199 | It's not up to this NIP to define how individual vending machines should choose to run their business. | 199 | It's not up to this NIP to define how individual vending machines should choose to run their business. |
| 200 | 200 | ||
| 201 | # Cancellation | 201 | # Cancellation |
| 202 | A job request might be canceled by publishing a `kind:5` delete request event tagging the job request event. | 202 | A job request might be canceled by publishing a `kind:5` retract request event tagging the job request event. |
| 203 | 203 | ||
| 204 | # Appendix 1: Job chaining | 204 | # Appendix 1: Job chaining |
| 205 | A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type. | 205 | A Customer MAY request multiple jobs to be processed as a chain, where the output of a job is the input of another job. (e.g. podcast transcription -> summarization of the transcription). This is done by specifying as input an event id of a different job with the `job` type. |
| @@ -30,7 +30,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | |||
| 30 | - [NIP-06: Basic key derivation from mnemonic seed phrase](06.md) | 30 | - [NIP-06: Basic key derivation from mnemonic seed phrase](06.md) |
| 31 | - [NIP-07: `window.nostr` capability for web browsers](07.md) | 31 | - [NIP-07: `window.nostr` capability for web browsers](07.md) |
| 32 | - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md) | 32 | - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md) |
| 33 | - [NIP-09: Event Deletion](09.md) | 33 | - [NIP-09: Event Retraction](09.md) |
| 34 | - [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md) | 34 | - [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md) |
| 35 | - [NIP-11: Relay Information Document](11.md) | 35 | - [NIP-11: Relay Information Document](11.md) |
| 36 | - [NIP-13: Proof of Work](13.md) | 36 | - [NIP-13: Proof of Work](13.md) |
| @@ -99,7 +99,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | |||
| 99 | | `2` | Recommend Relay | 01 (deprecated) | | 99 | | `2` | Recommend Relay | 01 (deprecated) | |
| 100 | | `3` | Follows | [02](02.md) | | 100 | | `3` | Follows | [02](02.md) | |
| 101 | | `4` | Encrypted Direct Messages | [04](04.md) | | 101 | | `4` | Encrypted Direct Messages | [04](04.md) | |
| 102 | | `5` | Event Deletion | [09](09.md) | | 102 | | `5` | Event Retraction | [09](09.md) | |
| 103 | | `6` | Repost | [18](18.md) | | 103 | | `6` | Repost | [18](18.md) | |
| 104 | | `7` | Reaction | [25](25.md) | | 104 | | `7` | Reaction | [25](25.md) | |
| 105 | | `8` | Badge Award | [58](58.md) | | 105 | | `8` | Badge Award | [58](58.md) | |