nchat

NIP-17 Fix kind number

01.md

@@ -78,8 +78,8 @@ This NIP defines 3 standard tags that can be used across all event kinds with th
 - The `e` tag, used to refer to an event: `["e", <32-bytes lowercase hex of the id of another event>, <recommended relay URL, optional>]`
 - The `p` tag, used to refer to another user: `["p", <32-bytes lowercase hex of a pubkey>, <recommended relay URL, optional>]`
 - The `a` tag, used to refer to a (maybe parameterized) replaceable event
-    - for a parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
-    - for a non-parameterized replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
+    - for an addressable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]`
+    - for a normal replaceable event: `["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:, <recommended relay URL, optional>]`
 
 As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event `"5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"` by using the `{"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]}` filter.
 

09.md

@@ -1,14 +1,14 @@
 NIP-09
 ======
 
-Event Deletion
+Event Deletion Request
 --------------
 
 `draft` `optional`
 
-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.
+A special event with kind `5`, meaning "deletion request" 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 requested for deletion.
 
-The event's `content` field MAY contain a text note describing the reason for the deletion.
+The event's `content` field MAY contain a text note describing the reason for the deletion request.
 
 For example:
 
@@ -28,24 +28,26 @@ 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.  Clients SHOULD hide or otherwise indicate a deletion request 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.
+Relays SHOULD continue to publish/share the deletion request events indefinitely, as clients may already have the event that's intended to be deleted. Additionally, clients SHOULD broadcast deletion request events to other relays which don't have it.
 
-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.
+When an `a` tag is used, relays SHOULD delete all versions of the replaceable event up to the `created_at` timestamp of the deletion request event.
 
 ## 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.
+Clients MAY choose to fully hide any events that are referenced by valid deletion request 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 request 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.
 
-Clients display the deletion event itself in any way they choose, e.g., not at all, or with a prominent notice.
+Clients display the deletion request event itself in any way they choose, e.g., not at all, or with a prominent notice.
+
+Clients MAY choose to inform the user that their request for deletion does not guarantee deletion because it is impossible to delete events from all relays and clients.
 
 ## 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 request event only references events that have the same `pubkey` as the deletion request itself, however this is not required since relays may not have knowledge of all referenced events.
 
-## Deleting a Deletion
+## Deletion Request of a Deletion Request
 
-Publishing a deletion event against a deletion has no effect.  Clients and relays are not obliged to support "undelete" functionality.
+Publishing a deletion request event against a deletion request has no effect.  Clients and relays are not obliged to support "unrequest deletion" functionality.

13.md

@@ -103,16 +103,6 @@ function countLeadingZeroes(hex) {
 }
 ```
 
-Querying relays for PoW notes
------------------------------
-
-If relays allow searching on prefixes, you can use this as a way to filter notes of a certain difficulty:
-
-```
-$ echo '["REQ", "subid", {"ids": ["000000000"]}]'  | websocat wss://some-relay.com | jq -c '.[2]'
-{"id":"000000000121637feeb68a06c8fa7abd25774bdedfa9b6ef648386fb3b70c387", ...}
-```
-
 Delegated Proof of Work
 -----------------------
 

15.md

@@ -300,7 +300,7 @@ This event leverages naddr to enable comprehensive customization and sharing of
 Bids are simply events of kind `1021` with a `content` field specifying the amount, in the currency of the auction. Bids must reference an auction.
 
 > [!NOTE]
-> Auctions can be edited as many times as desired (they are "parameterized replaceable events") by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one "version". Editing the auction after a bid would result in the new product losing the bid!
+> Auctions can be edited as many times as desired (they are "addressable events") by the author - even after the start_date, but they cannot be edited after they have received the first bid! This is enforced by the fact that bids reference the event ID of the auction (rather than the product UUID), which changes with every new version of the auctioned product. So a bid is always attached to one "version". Editing the auction after a bid would result in the new product losing the bid!
 
 ### Event `1022`: Bid confirmation
 

17.md

@@ -102,7 +102,7 @@ Clients SHOULD publish kind `14` events to the `10050`-listed relays. If that is
 
 ## Relays
 
-It's advisable that relays do not serve `kind:14` to clients other than the ones tagged in them.
+It's advisable that relays do not serve `kind:1059` to clients other than the ones tagged in them.
 
 It's advisable that users choose relays that conform to these practices.
 
@@ -123,6 +123,11 @@ This NIP offers the following privacy and security features:
 
 The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.
 
+## NIP-19 entity
+To create an `nchat` link:
+  - `kind`: `17`
+  - `special`: one or more pubkeys concatenated
+
 ## Implementation
 
 Clients implementing this NIP should by default only connect to the set of relays found in their `kind:10050` list. From that they should be able to load all messages both sent and received as well as get new live updates, making it for a very simple and lightweight implementation that should be fast.

19.md

@@ -36,6 +36,7 @@ These are the possible bech32 prefixes with `TLV`:
   - `nevent`: a nostr event
   - `naddr`: a nostr _replaceable event_ coordinate
   - `nrelay`: a nostr relay (deprecated)
+  - `nchat`: a nostr chat conversation
 
 These possible standardized `TLV` types are indicated here:
 
@@ -43,7 +44,8 @@ These possible standardized `TLV` types are indicated here:
   - depends on the bech32 prefix:
     - for `nprofile` it will be the 32 bytes of the profile public key
     - for `nevent` it will be the 32 bytes of the event id
-    - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For non-parameterized replaceable events, use an empty string.
+    - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For normal replaceable events use an empty string.
+    - for `nchat`, see chat nip for details.
 - `1`: `relay`
   - for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
   - this may be included multiple times
@@ -53,6 +55,7 @@ These possible standardized `TLV` types are indicated here:
 - `3`: `kind`
   - for `naddr`, the 32-bit unsigned integer of the kind, big-endian
   - for `nevent`, _optionally_, the 32-bit unsigned integer of the kind, big-endian
+  - for `nchat`, the NIP number of the chat.
 
 ## Examples
 

23.md

@@ -6,7 +6,7 @@ Long-form Content
 
 `draft` `optional`
 
-This NIP defines `kind:30023` (a _parameterized replaceable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts.
+This NIP defines `kind:30023` (an _addressable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts.
 
 "Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
 

24.md

@@ -39,5 +39,7 @@ tags
 
 These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:
 
-  - `r`: a web URL the event is referring to in some way
-  - `title`: name of [NIP-51](51.md) sets, [NIP-52](52.md) calendar event, [NIP-53](53.md) live event or [NIP-99](99.md) listing
+  - `r`: a web URL the event is referring to in some way.
+  - `i`: an external id the event is referring to in some way - see [NIP-73](73.md).
+  - `title`: name of [NIP-51](51.md) sets, [NIP-52](52.md) calendar event, [NIP-53](53.md) live event or [NIP-99](99.md) listing.
+  - `t`: a hashtag. The value MUST be a lowercase string.

25.md

@@ -52,6 +52,26 @@ func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> Nost
 }
 ```
 
+Reactions to a website
+---------------------
+
+If the target of the reaction is a website, the reaction MUST be a `kind 17` event and MUST include an `r` tag with the website's URL.
+
+```json
+{
+  "kind": 17,
+  "content": "⭐",
+  "tags": [
+    ["r", "https://example.com/"]
+  ],
+  ...other fields
+}
+```
+
+URLs SHOULD be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6), so that reactions to the same website are not omitted from queries.
+A fragment MAY be attached to the URL, to react to a section of the page.
+It should be noted that a URL with a fragment is not considered to be the same URL as the original.
+
 Custom Emoji Reaction
 ---------------------
 

28.md

@@ -133,6 +133,11 @@ Clients MAY hide event 42s for users other than the user who sent the event 44.
 }
 ```
 
+## NIP-19 entity
+To create an `nchat` link:
+  - `kind`: `28`
+  - `special`: `id` from `kind: 40`
+
 ## Relay recommendations
 
 Clients SHOULD use the relay URLs of the metadata events. 

29.md

@@ -16,7 +16,7 @@ Normally a group will originally belong to one specific relay, but the community
 
 ## Relay-generated events
 
-Relays are supposed to generate the events that describe group metadata and group admins. These are parameterized replaceable events signed by the relay keypair directly, with the group _id_ as the `d` tag.
+Relays are supposed to generate the events that describe group metadata and group admins. These are _addressable_ events signed by the relay keypair directly, with the group _id_ as the `d` tag.
 
 ## Group identifier
 
@@ -93,6 +93,20 @@ Any user can send one of these events to the relay in order to be automatically
 }
 ```
 
+- *leave request* (`kind:9022`)
+
+Any user can send one of these events to the relay in order to be automatically removed from the group. The relay will automatically issue a `kind:9001` in response removing this user.
+
+```js
+{
+  "kind": 9022,
+  "content": "optional reason",
+  "tags": [
+    ["h", "<group-id>"]
+  ]
+}
+```
+
 - *moderation events* (`kinds:9000-9020`) (optional)
 
 Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action. The relay may discard the event after taking action or keep it as a moderation log.
@@ -120,6 +134,7 @@ Each moderation action uses a different kind and requires different arguments, w
 | 9005 | `delete-event`      | `e` (id hex)                              |
 | 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
 | 9007 | `create-group`      |                                           |
+| 9008 | `delete-group`      |                                           |
 
 - *group metadata* (`kind:39000`) (optional)
 
@@ -160,6 +175,7 @@ The list of capabilities, as defined by this NIP, for now, is the following:
 - `add-permission`
 - `remove-permission`
 - `edit-group-status`
+- `delete-group`
 
 ```js
 {

32.md

@@ -145,7 +145,7 @@ Author is labeling their note language as English using ISO-639-1.
 Other Notes
 -----------
 
-When using this NIP to bulk-label many targets at once, events may be deleted and a replacement
+When using this NIP to bulk-label many targets at once, events may be requested for deletion using [NIP-09](09.md) and a replacement
 may be published. We have opted not to use parameterizable/replaceable events for this due to the
 complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying,
 publishers SHOULD limit labeling events to a single namespace.

33.md

@@ -6,4 +6,4 @@ Parameterized Replaceable Events
 
 `final` `mandatory`
 
-Moved to [NIP-01](01.md).
+Renamed to "Addressable events" and moved to [NIP-01](01.md).

34.md

@@ -53,7 +53,7 @@ An optional source of truth for the state of branches and tags in a repository.
 
 The `refs` tag may appear multiple times, or none.
 
-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.
+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 requests.
 
 The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is:
 

38.md

@@ -13,7 +13,7 @@ This NIP enables a way for users to share live statuses such as what music they
 
 ## Live Statuses
 
-A special event with `kind:30315` "User Status" is defined as an *optionally expiring* _parameterized replaceable event_, where the `d` tag represents the status type:
+A special event with `kind:30315` "User Status" is defined as an *optionally expiring* _addressable event_, where the `d` tag represents the status type:
 
 For example:
 

45.md

@@ -16,14 +16,14 @@ Some queries a client may want to execute against connected relays are prohibiti
 
 This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
 
-```json
+```
 ["COUNT", <subscription_id>, <filters JSON>...]
 ```
 
 Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
 In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
 
-```json
+```
 ["COUNT", <subscription_id>, {"count": <integer>}]
 ```
 
@@ -33,14 +33,14 @@ Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST ret
 
 ### Followers count
 
-```json
+```
 ["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
 ["COUNT", <subscription_id>, {"count": 238}]
 ```
 
 ### Count posts and reactions
 
-```json
+```
 ["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
 ["COUNT", <subscription_id>, {"count": 5}]
 ```

51.md

@@ -16,7 +16,7 @@ When new items are added to an existing list, clients SHOULD append them to the
 
 ## Standard lists
 
-Standard lists use non-parameterized replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
+Standard lists use normal replaceable events, meaning users may only have a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience.
 
 For example, _mute list_ can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive annoying notifications from.
 
@@ -51,6 +51,7 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | Bookmark sets | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs) |
 | Curation sets | 30004 | groups of articles picked by users as interesting and/or belonging to the same category      | `"a"` (kind:30023 articles), `"e"` (kind:1 notes)                                 |
 | Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"a"` (kind:34235 videos)                                                         |
+| Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string                                  | `"p"` (pubkeys)                                                                   |
 | Interest sets | 30015 | interest topics represented by a bunch of "hashtags"                                         | `"t"` (hashtags)                                                                  |
 | Emoji sets    | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                   |
 | Release artifact sets | 30063 | groups of files of a software release  | `"e"` (kind:1063 [file metadata](94.md) events), `"i"` (application identifier, typically reverse domain notation), `"version"`  |

52.md

@@ -6,7 +6,7 @@ Calendar Events
 
 `draft` `optional`
 
-This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _parameterized replaceable_ and deletable per [NIP-09](09.md).
+This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _addressable_ and deletable per [NIP-09](09.md).
 
 Unlike the term `calendar event` specific to this NIP, the term `event` is used broadly in all the NIPs to describe any Nostr event. The distinction is being made here to discern between the two terms.
 
@@ -90,9 +90,12 @@ The list of tags are as follows:
 * `end` (optional) exclusive end Unix timestamp in seconds. If omitted, the calendar event ends instantaneously.
 * `start_tzid` (optional) time zone of the start timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`
 * `end_tzid` (optional) time zone of the end timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`. If omitted and `start_tzid` is provided, the time zone of the end timestamp is the same as the start timestamp.
+* `summary` (optional) brief description of the calendar event
+* `image` (optional) url of an image to use for the event
 * `location` (optional, repeated) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
 * `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location
 * `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
+* `l` (optional, repeated) label to categorize calendar event. e.g. `audiospace` to denote a scheduled event from a live audio space implementation such as cornychat.com
 * `t` (optional, repeated) hashtag to categorize calendar event
 * `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
 
@@ -110,6 +113,8 @@ The following tags are deprecated:
     ["d", "<UUID>"],
 
     ["title", "<title of calendar event>"],
+    ["summary", "<brief description of the calendar event>"],
+    ["image", "<string with image URI>"],
 
     // Timestamps
     ["start", "<Unix timestamp in seconds>"],
@@ -126,6 +131,10 @@ The following tags are deprecated:
     ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
     ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
 
+    // Labels (example using com.cornychat namespace denoting the event as an audiospace)
+    ["L", "com.cornychat"],
+    ["l", "audiospace", "com.cornychat"],
+
     // Hashtags
     ["t", "<tag>"],
     ["t", "<tag>"],
@@ -178,6 +187,10 @@ This NIP is intentionally not defining who is authorized to attend a calendar ev
 
 This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted.
 
+The RSVP MUST have an `a` tag of the event coordinates to the calendar event, and optionally an `e` tag of the id of the specific calendar event revision. If an `e` tag is present, clients SHOULD interpret it as an indication that the RSVP is a response to that revision of the calendar event, and MAY interpret it to not necessarily apply to other revisions of the calendar event.
+
+The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author.
+
 ### Format
 
 The format uses a parameterized replaceable event kind `31925`.
@@ -185,10 +198,12 @@ The format uses a parameterized replaceable event kind `31925`.
 The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.
 
 The list of tags are as follows:
-* `a` (required) reference tag to kind `31922` or `31923` calendar event being responded to.
+* `a` (required) coordinates to a kind `31922` or `31923` calendar event being responded to.
+* `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to.
 * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP.
 * `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event.
 * `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`.
+* `p` (optional) pubkey of the author of the calendar event being responded to.
 
 ```json
 {
@@ -198,10 +213,12 @@ The list of tags are as follows:
   "kind": 31925,
   "content": "<note>",
   "tags": [
-    ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],
+    ["e", "<kind 31922 or 31923 event id", "<optional recommended relay URL>"]
+    ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional recommended relay URL>"],
     ["d", "<UUID>"],
     ["status", "<accepted/declined/tentative>"],
     ["fb", "<free/busy>"],
+    ["p", "<hex pubkey of kind 31922 or 31923 event>", "<optional recommended relay URL>"]
   ]
 }
 ```

53.md

@@ -12,7 +12,7 @@ Service providers want to offer live activities to the Nostr network in such a w
 
 ### Live Event
 
-A special event with `kind:30311` "Live Event" is defined as a _parameterized replaceable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
+A special event with `kind:30311` "Live Event" is defined as an _addressable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
 
 For example:
 

54.md

@@ -6,7 +6,7 @@ Wiki
 
 `draft` `optional`
 
-This NIP defines `kind:30818` (a _parameterized replaceable event_) for long-form text content similar to [NIP-23](23.md), but with one important difference: articles are meant to be descriptions, or encyclopedia entries, of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
+This NIP defines `kind:30818` (an _addressable event_) for long-form text content similar to [NIP-23](23.md), but with one important difference: articles are meant to be descriptions, or encyclopedia entries, of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content.
 
 Articles are identified by lowercase, normalized ascii `d` tags.
 
@@ -28,13 +28,13 @@ Articles are identified by lowercase, normalized ascii `d` tags.
 
 ### Content rules
 
-The content should be Markdown, following the same rules as of [NIP-23](23.md), although it takes some extra (optional) metadata tags:
+The content should be Asciidoc, following the same rules as of [NIP-23](23.md), although it takes some extra (optional) metadata tags:
 
   - `title`: for when the display title should be different from the `d` tag.
   - `summary`: for display in lists.
   - `a` and `e`: for referencing the original event a wiki article was forked from.
 
-One extra functionality is added: **wikilinks**. Unlike normal Markdown links `[]()` that link to webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink.
+One extra functionality is added: **wikilinks**. Unlike normal Asciidoc links `[]()` that link to webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink.
 
 Wikilinks can take these two forms:
 
@@ -86,12 +86,12 @@ This is a stronger signal of trust than a `+` reaction.
 
 This marker is useful when a user edits someone else's entry; if the original author includes the editor's changes and the editor doesn't want to keep/maintain an independent version, the `link` tag could effectively be a considered a "deletion" of the editor's version and putting that pubkey's WoT weight behind the original author's version.
 
-Why Markdown?
+Why Asciidoc?
 -------------
 
-If the idea is to make a wiki then the most obvious text format to use is probably the mediawiki/wikitext format used by Wikipedia since it's widely deployed in all mediawiki installations and used for decades with great success. However, it turns out that format is very bloated and convoluted, has way too many features and probably because of that it doesn't have many alternative implementations out there, and the ones that exist are not complete and don't look very trustworthy. Also it is very much a centralized format that can probably be changed at the whims of the Wikipedia owners.
+Wikitext is [garbage](nostr:nevent1qqsqt0gcggry60n72uglhuhypdlmr2dm6swjj69jex5v530gcpazlzsprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5ueneex) and Markdown is not powerful enough (besides being too freeform and unspecified and prone to generate incompatibilities in the future).
 
-On the other hand, Markdown has proven to work well for small scale wikis and one of the biggest wikis in the planet (which is not very often thought of as a wiki), [StackOverflow](https://stackoverflow.com) and its child sites, and also one of the biggest "personal wiki" software, [Obsidian](https://obsidian.md/). Markdown can probably deliver 95% of the functionality of wikitext. When augmented with tables, diagram generators and MathJax (which are common extensions that exist in the wild and can be included in this NIP) that rate probably goes to 99%, and its simplicity is a huge benefit that can't be overlooked. Wikitext format can also be transpíled into Markdown using Pandoc. Given all that, I think it's a reasonable suspicion that mediawiki is not inherently better than Markdown, the success of Wikipedia probably cannot be predicated on the syntax language choice.
+Asciidoc has a strict spec, multiple implementations in many languages, and support for features that are very much necessary in a wiki article, like _sidebars_, _tables_ (with rich markup inside cells), many levels of _headings_, _footnotes_, _superscript_ and _subscript_ markup and _description lists_. It is also arguably easier to read in its plaintext format than Markdown (and certainly much better than Wikitext).
 
 # Appendix 1: Merge requests
 Users can request other users to get their entries merged into someone else's entry by creating a `kind:818` event.

57.md

@@ -36,7 +36,7 @@ A `zap request` is an event of kind `9734` that is _not_ published to relays, bu
 In addition, the event MAY include the following tags:
 
 - `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person.
-- `a` is an optional event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes.
+- `a` is an optional event coordinate that allows tipping addressable events such as NIP-23 long-form notes.
 
 Example:
 

58.md

@@ -9,7 +9,7 @@ Badges
 Three special events are used to define, award and display badges in
 user profiles:
 
-1. A "Badge Definition" event is defined as a parameterized replaceable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
+1. A "Badge Definition" event is defined as an addressable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
 
 2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. Awarded badges are immutable and non-transferrable.
 

64.md

@@ -0,0 +1,146 @@
+NIP-64
+======
+
+Chess (Portable Game Notation)
+-----
+
+`draft` `optional`
+
+This NIP defines `kind:64` notes representing chess games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software.
+
+## Note
+
+### Content
+
+The `.content` of these notes is a string representing a [PGN-database][pgn_formal_syntax].
+
+### Notes
+
+```json
+{
+  "kind": 64,
+  "content": "1. e4 *",
+  ...
+}
+```
+
+```json
+{
+  "kind": 64,
+  "tags": [
+    ["alt", "Fischer vs. Spassky in Belgrade on 1992-11-04 (F/S Return Match, Round 29)"],
+    ...
+  ],
+  "content": "[Event \"F/S Return Match\"]\n[Site \"Belgrade, Serbia JUG\"]\n[Date \"1992.11.04\"]\n[Round \"29\"]\n[White \"Fischer, Robert J.\"]\n[Black \"Spassky, Boris V.\"]\n[Result \"1/2-1/2\"]\n\n1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6\n4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7\n11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5\nNxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6\n23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5\nhxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5\n35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6\nNf2 42. g4 Bd3 43. Re6 1/2-1/2"
+  ...
+}
+```
+
+## Client Behavior
+
+Clients SHOULD display the content represented as chessboard.
+
+Clients SHOULD publish PGN notes in ["export format"][pgn_export_format] ("strict mode", i.e. created by machines) but expect incoming notes to be in ["import format"][pgn_import_format] ("lax mode", i.e. created by humans).
+
+Clients SHOULD check whether the formatting is valid and all moves comply with chess rules.
+
+Clients MAY include additional tags (e.g. like [`"alt"`](https://github.com/nostr-protocol/nips/blob/master/31.md)) in order to represent the note to users of non-supporting clients.
+
+## Relay Behavior
+
+Relays MAY validate PGN contents and reject invalid notes.
+
+
+## Examples
+
+```pgn
+// A game where nothing is known. Game still in progress, game abandoned, or result otherwise unknown. 
+// Maybe players died before a move has been made.
+*
+```
+
+```pgn
+1. e4 *
+```
+
+```pgn
+[White "Fischer, Robert J."]
+[Black "Spassky, Boris V."]
+
+1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} *
+```
+
+```pgn
+[Event "F/S Return Match"]
+[Site "Belgrade, Serbia JUG"]
+[Date "1992.11.04"]
+[Round "29"]
+[White "Fischer, Robert J."]
+[Black "Spassky, Boris V."]
+[Result "1/2-1/2"]
+
+1. e4 e5 2. Nf3 Nc6 3. Bb5 {This opening is called the Ruy Lopez.} 3... a6
+4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7
+11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5
+Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6
+23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5
+hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5
+35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6
+Nf2 42. g4 Bd3 43. Re6 1/2-1/2
+```
+
+```pgn
+[Event "Hourly HyperBullet Arena"]
+[Site "https://lichess.org/wxx4GldJ"]
+[Date "2017.04.01"]
+[White "T_LUKE"]
+[Black "decidement"]
+[Result "1-0"]
+[UTCDate "2017.04.01"]
+[UTCTime "11:56:14"]
+[WhiteElo "2047"]
+[BlackElo "1984"]
+[WhiteRatingDiff "+10"]
+[BlackRatingDiff "-7"]
+[Variant "Standard"]
+[TimeControl "30+0"]
+[ECO "B00"]
+[Termination "Abandoned"]
+
+1. e4 1-0
+
+
+[Event "Hourly HyperBullet Arena"]
+[Site "https://lichess.org/rospUdSk"]
+[Date "2017.04.01"]
+[White "Bastel"]
+[Black "oslochess"]
+[Result "1-0"]
+[UTCDate "2017.04.01"]
+[UTCTime "11:55:56"]
+[WhiteElo "2212"]
+[BlackElo "2000"]
+[WhiteRatingDiff "+6"]
+[BlackRatingDiff "-4"]
+[Variant "Standard"]
+[TimeControl "30+0"]
+[ECO "A01"]
+[Termination "Normal"]
+
+1. b3 d5 2. Bb2 c6 3. Nc3 Bf5 4. d4 Nf6 5. e3 Nbd7 6. f4 Bg6 7. Nf3 Bh5 8. Bd3 e6 9. O-O Be7 10. Qe1 O-O 11. Ne5 Bg6 12. Nxg6 hxg6 13. e4 dxe4 14. Nxe4 Nxe4 15. Bxe4 Nf6 16. c4 Bd6 17. Bc2 Qc7 18. f5 Be7 19. fxe6 fxe6 20. Qxe6+ Kh8 21. Qh3+ Kg8 22. Bxg6 Qd7 23. Qe3 Bd6 24. Bf5 Qe7 25. Be6+ Kh8 26. Qh3+ Nh7 27. Bf5 Rf6 28. Qxh7# 1-0
+```
+
+## Resources
+- [PGN Specification][pgn_specification]: PGN (Portable Game Notation) specification
+- [PGN Specification Supplement](https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-spec-supplement.md): Addition for adding graphical elements, clock values, eval, ...
+- [PGN Formal Syntax][pgn_formal_syntax]
+- [PGN Seven Tag Roster][pgn_seven_tag_roster]
+- [PGN Import Format][pgn_import_format]
+- [PGN Export Format][pgn_export_format]
+- [lichess / pgn-viewer (GitHub)](https://github.com/lichess-org/pgn-viewer): PGN viewer widget, designed to be embedded in content pages
+
+[pgn_specification]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md
+[pgn_formal_syntax]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#18-formal-syntax
+[pgn_seven_tag_roster]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#811-seven-tag-roster
+[pgn_import_format]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#31-import-format-allows-for-manually-prepared-data
+[pgn_export_format]: https://github.com/mliebelt/pgn-spec-commented/blob/main/pgn-specification.md#32-export-format-used-for-program-generated-output

71.md

@@ -6,7 +6,7 @@ Video Events
 
 `draft` `optional`
 
-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).
+This specification defines video events representing a dedicated post of externally hosted content. These video events are _addressable_ and delete-requestable per [NIP-09](09.md).
 
 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.
 

72.md

@@ -62,7 +62,7 @@ An approval event MUST include one or more community `a` tags, an `e` or `a` tag
 
 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.
 
-Moderators MAY delete their approval of a post at any time using NIP 09 event deletions.
+Moderators MAY request deletion of their approval of a post at any time using [NIP-09 event deletion requests](09.md).
 
 ```jsonc
 {

73.md

@@ -0,0 +1,48 @@
+NIP-73
+======
+
+External Content IDs
+-------------------------
+
+`draft` `optional`
+
+There are certain established global content identifiers that would be useful to reference in nostr events so that clients can query all events assosiated with these ids.
+
+- Book [ISBNs](https://en.wikipedia.org/wiki/ISBN)
+- Podcast [GUIDs](https://podcastnamespace.org/tag/guid)
+- Movie [ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number)
+
+Since the `i` tag is already used for similar references in kind-0 metadata events it makes sense to use it for these content ids as well.
+
+
+## Supported IDs
+
+### Books:
+
+- Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
+
+Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs return the ISBNs without hyphens. Removing hypens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.
+
+### Podcasts:
+
+- Podcast RSS Feed GUID: `["i", "podcast:guid:c90e609a-df1e-596a-bd5e-57bcc8aad6cc"]` - https://podcastindex.org/podcast/c90e609a-df1e-596a-bd5e-57bcc8aad6cc
+- Podcast RSS Item GUID: `["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f"]`
+- Podcast RSS Publisher GUID: `["i", "podcast:publisher:guid:18bcbf10-6701-4ffb-b255-bc057390d738"]`
+
+### Movies:
+
+- Movie ISAN: `["i", "isan:0000-0000-401A-0000-7"]` - https://web.isan.org/public/en/isan/0000-0000-401A-0000-7
+
+Movie ISANs SHOULD be referenced  _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here -  https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry
+
+---
+
+### Optional URL Hints
+
+Each `i` tag MAY have a url hint as the second argument to redirect people to a website if the client isn't opinionated about how to interpret the id:
+
+`["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]`
+
+`["i", "isan:0000-0000-401A-0000-7", https://www.imdb.com/title/tt0120737]`
+
+

74.md

@@ -1,29 +0,0 @@
-NIP-74
-======
-
-Addressable Chat
-----------------
-
-`draft` `optional`
-
-Every time an addressable event (kinds 30000-39999) contains a `"relays"` tag with any number of relay URLs specified in it (`["relays", "wss://myrelay.com", "wss://addressable.chat"]`) clients have the option of toggling a chat box about the topic of that event.
-
-Chat messages are expected to be read and published from and to the specified relays, which will _somehow_ provide moderation and consistency.
-
-(Clients can also use different relays other than those specified by the addressable event author, but this would be a power/optional/manual feature until other means of signaling this are invented.)
-
-### Chat Message
-
-Chat messages must have `kind:1311`. Clients MUST include the `a` tag of the activity with a `root` marker. Other Kind-1 tags such as `reply` and `mention` can also be used. An `e` tag containing the specific ID of the current addressable event version being replied to SHOULD also be included.
-
-```json
-{
-  "kind": 1311,
-  "tags": [
-    ["a", "<addressable-event-kind>:<addressable-author-pubkey>:<d-identifier>", "<optional relay url>", "root"],
-    ["e", "<addressable-event-id>", "<optional relay url>", "root"]
-  ],
-  "content": "hello fans of this article",
-  ...
-}
-```

75.md

@@ -53,11 +53,11 @@ The following tags are OPTIONAL.
 }
 ```
 
-The goal MAY include an `r` or `a` tag linking to a URL or parameterized replaceable event.
+The goal MAY include an `r` or `a` tag linking to a URL or addressable event.
 
 The goal MAY include multiple beneficiary pubkeys by specifying [`zap` tags](57.md#appendix-g-zap-tag-on-other-events).
 
-Parameterized replaceable events can link to a goal by using a `goal` tag specifying the event id and an optional relay hint.
+Addressable events can link to a goal by using a `goal` tag specifying the event id and an optional relay hint.
 
 ```json
 {

78.md

@@ -12,7 +12,7 @@ Even though interoperability is great, some apps do not want or do not need inte
 
 ## Nostr event
 
-This NIP specifies the use of event kind `30078` (parameterized replaceable event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format.
+This NIP specifies the use of event kind `30078` (an _addressable_ event) with a `d` tag containing some reference to the app name and context -- or any other arbitrary string. `content` and other `tags` can be anything or in any format.
 
 ## Some use cases
 

99.md

@@ -6,7 +6,7 @@ Classified Listings
 
 `draft` `optional`
 
-This NIP defines `kind:30402`: a parameterized replaceable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
+This NIP defines `kind:30402`: an addressable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
 
 The category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in [NIP-15](15.md) that often sell many units of specific products through very specific channels.
 

BREAKING.md

@@ -5,6 +5,7 @@ reverse chronological order.
 
 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
+| 2024-08-18  | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [NIP-54](54.md) | content should be Asciidoc |
 | 2024-07-31  | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [NIP-45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
 | 2024-07-30  | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [NIP-45](45.md) | NIP-45 was deprecated |
 | 2024-07-26  | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [NIP-19](19.md) | `nrelay` was deprecated |
@@ -47,6 +48,7 @@ reverse chronological order.
 | 2023-06-18  | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [NIP-11](11.md) | 'image' was renamed to 'icon' |
 | 2023-04-13  | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [NIP-15](15.md) | different NIP was re-added as NIP-15 |
 | 2023-04-09  | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [NIP-15](15.md) | NIP-15 was merged into NIP-01 |
+| 2023-03-29  | [599e1313](https://github.com/nostr-protocol/nips/commit/599e1313) | [NIP-18](18.md) | NIP-18 was bring back |
 | 2023-03-15  | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [NIP-19](19.md) | `1: relay` was changed to optionally |
 
 Breaking changes prior to 2023-03-01 are not yet documented.

README.md

@@ -30,7 +30,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-06: Basic key derivation from mnemonic seed phrase](06.md)
 - [NIP-07: `window.nostr` capability for web browsers](07.md)
 - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
-- [NIP-09: Event Deletion](09.md)
+- [NIP-09: Event Deletion Request](09.md)
 - [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md)
 - [NIP-11: Relay Information Document](11.md)
 - [NIP-13: Proof of Work](13.md)
@@ -73,10 +73,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-57: Lightning Zaps](57.md)
 - [NIP-58: Badges](58.md)
 - [NIP-59: Gift Wrap](59.md)
+- [NIP-64: Chess (PGN)](64.md)
 - [NIP-65: Relay List Metadata](65.md)
 - [NIP-70: Protected Events](70.md)
 - [NIP-71: Video Events](71.md)
 - [NIP-72: Moderated Communities](72.md)
+- [NIP-73: External Content IDs](73.md)
 - [NIP-75: Zap Goals](75.md)
 - [NIP-78: Application-specific data](78.md)
 - [NIP-84: Highlights](84.md)
@@ -97,7 +99,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `2`           | Recommend Relay                 | 01 (deprecated)                        |
 | `3`           | Follows                         | [02](02.md)                            |
 | `4`           | Encrypted Direct Messages       | [04](04.md)                            |
-| `5`           | Event Deletion                  | [09](09.md)                            |
+| `5`           | Event Deletion Request          | [09](09.md)                            |
 | `6`           | Repost                          | [18](18.md)                            |
 | `7`           | Reaction                        | [25](25.md)                            |
 | `8`           | Badge Award                     | [58](58.md)                            |
@@ -108,11 +110,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `13`          | Seal                            | [59](59.md)                            |
 | `14`          | Direct Message                  | [17](17.md)                            |
 | `16`          | Generic Repost                  | [18](18.md)                            |
+| `17`          | Reaction to a website           | [25](25.md)                            |
 | `40`          | Channel Creation                | [28](28.md)                            |
 | `41`          | Channel Metadata                | [28](28.md)                            |
 | `42`          | Channel Message                 | [28](28.md)                            |
 | `43`          | Channel Hide Message            | [28](28.md)                            |
 | `44`          | Channel Mute User               | [28](28.md)                            |
+| `64`          | Chess (PGN)                     | [64](64.md)                            |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1021`        | Bid                             | [15](15.md)                            |
 | `1022`        | Bid confirmation                | [15](15.md)                            |
@@ -238,15 +242,15 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `-`               | --                                   | --                              | [70](70.md)                           |
 | `g`               | geohash                              | --                              | [52](52.md)                           |
 | `h`               | group id                             | --                              | [29](29.md)                           |
-| `i`               | identity                             | proof                           | [39](39.md)                           |
+| `i`               | external identity                    | proof, url hint                 | [39](39.md), [73](73.md)              |
 | `k`               | kind number (string)                 | --                              | [18](18.md), [25](25.md), [72](72.md) |
 | `l`               | label, label namespace               | --                              | [32](32.md)                           |
 | `L`               | label namespace                      | --                              | [32](32.md)                           |
 | `m`               | MIME type                            | --                              | [94](94.md)                           |
 | `q`               | event id (hex)                       | relay URL                       | [18](18.md)                           |
-| `r`               | a reference (URL, etc)               | petname                         | [24](24.md)                           |
+| `r`               | a reference (URL, etc)               | --                              | [24](24.md), [25](25.md)              |
 | `r`               | relay url                            | marker                          | [65](65.md)                           |
-| `t`               | hashtag                              | --                              |                                       |
+| `t`               | hashtag                              | --                              | [24](24.md)                           |
 | `alt`             | summary                              | --                              | [31](31.md)                           |
 | `amount`          | millisatoshis, stringified           | --                              | [57](57.md)                           |
 | `bolt11`          | `bolt11` invoice                     | --                              | [57](57.md)                           |
@@ -260,7 +264,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `encrypted`       | --                                   | --                              | [90](90.md)                           |
 | `expiration`      | unix timestamp (string)              | --                              | [40](40.md)                           |
 | `goal`            | event id (hex)                       | relay URL                       | [75](75.md)                           |
-| `image`           | image URL                            | dimensions in pixels            | [23](23.md), [58](58.md)              |
+| `image`           | image URL                            | dimensions in pixels            | [23](23.md), [52](52.md), [58](58.md) |
 | `imeta`           | inline metadata                      | --                              | [92](92.md)                           |
 | `lnurl`           | `bech32` encoded `lnurl`             | --                              | [57](57.md)                           |
 | `location`        | location string                      | --                              | [52](52.md), [99](99.md)              |
@@ -274,7 +278,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `relays`          | relay list                           | --                              | [57](57.md)                           |
 | `server`          | file storage server url              | --                              | [96](96.md)                           |
 | `subject`         | subject                              | --                              | [14](14.md), [17](17.md)              |
-| `summary`         | article summary                      | --                              | [23](23.md)                           |
+| `summary`         | summary                              | --                              | [23](23.md), [52](52.md)              |
 | `thumb`           | badge thumbnail                      | dimensions in pixels            | [58](58.md)                           |
 | `title`           | article title                        | --                              | [23](23.md)                           |
 | `web`             | webpage URL                          | --                              | [34](34.md)                           |