Skip to content

Commit

Permalink
Add ! as authorized deletion pubkey tag
Browse files Browse the repository at this point in the history
  • Loading branch information
arthurfranca committed Jul 4, 2023
1 parent e0fc913 commit 2c5adab
Show file tree
Hide file tree
Showing 3 changed files with 7 additions and 6 deletions.
8 changes: 4 additions & 4 deletions 09.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ NIP-09
Event Deletion
--------------

`draft` `optional` `author:scsibug`
`draft` `optional` `author:scsibug` `author:arthurfranca`

A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted.

Expand All @@ -28,21 +28,21 @@ For example:
}
```

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.
Relays SHOULD delete or stop publishing any referenced events that have an identical `pubkey` as the deletion request OR that have a `!` tag value equal to the deletion request `pubkey`. Clients SHOULD hide or otherwise indicate a deletion status for referenced events.

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.

## Client Usage

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.

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.
A client MUST validate that each event `pubkey` referenced in the `e` tag of the deletion request is identical to the deletion request `pubkey` OR that each referenced event has `!` tag value equal 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.

Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice.

## Relay Usage

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.
Relays MAY validate that a deletion event only references events that have the same `pubkey` as the deletion itself or that have a `!` tag value equal to the deletion `pubkey`, however this is not required since relays may not have knowledge of all referenced events.

## Deleting a Deletion

Expand Down
4 changes: 2 additions & 2 deletions 12.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Generic Tag Queries

Relays may support subscriptions over arbitrary tags. `NIP-01` requires relays to respond to queries for `e` and `p` tags. This NIP allows any single-letter tag present in an event to be queried.

The `<filters>` object described in `NIP-01` is expanded to contain arbitrary keys with a `#` prefix. Any single-letter key in a filter beginning with `#` is a tag query, and MUST have a value of an array of strings. The filter condition matches if the event has a tag with the same name, and there is at least one tag value in common with the filter and event. The tag name is the letter without the `#`, and the tag value is the second element. Subsequent elements are ignored for the purposes of tag queries.
The `<filters>` object described in `NIP-01` is expanded to contain arbitrary keys with a `#` prefix. Any single-letter or single exclamation mark key in a filter beginning with `#` is a tag query, and MUST have a value of an array of strings. The filter condition matches if the event has a tag with the same name, and there is at least one tag value in common with the filter and event. The tag name is the letter without the `#`, and the tag value is the second element. Subsequent elements are ignored for the purposes of tag queries.

Example Subscription Filter
---------------------------
Expand All @@ -30,7 +30,7 @@ Clients SHOULD use the `supported_nips` field to learn if a relay supports gener
Rationale
---------

The decision to reserve only single-letter tags to be usable in queries allow applications to make use of tags for all sorts of metadata, as it is their main purpose, without worrying that they might be bloating relay indexes. That also makes relays more lightweight, of course. And if some application or user is abusing single-letter tags with the intention of bloating relays that becomes easier to detect as single-letter tags will hardly be confused with some actually meaningful metadata some application really wanted to attach to the event with no spammy intentions.
The decision to reserve only single-letter (and single-char exclamation mark) tags to be usable in queries allow applications to make use of tags for all sorts of metadata, as it is their main purpose, without worrying that they might be bloating relay indexes. That also makes relays more lightweight, of course. And if some application or user is abusing single-letter tags with the intention of bloating relays that becomes easier to detect as single-letter tags will hardly be confused with some actually meaningful metadata some application really wanted to attach to the event with no spammy intentions.

Suggested Use Cases
-------------------
Expand Down
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -162,6 +162,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI
| `p` | pubkey (hex) | relay URL | [1](01.md) |
| `r` | a reference (URL, etc) | -- | [12](12.md) |
| `t` | hashtag | -- | [12](12.md) |
| `!` | authorized deletion pubkey (hex) | -- | [9](09.md) |
| `amount` | millisats | -- | [57](57.md) |
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `challenge` | challenge string | -- | [42](42.md) |
Expand Down

0 comments on commit 2c5adab

Please sign in to comment.