Update kind numbers to 34235 (normal videos) and 34236 (short videos)

Extends NIP-71 to support addressable video events for content that may need updates after publication. This enables:

- Metadata corrections without republishing
- URL migration when hosting changes
- Preservation of imported content IDs from legacy platforms
- Platform migration tracking

Adds kinds 32221 (normal videos) and 32222 (short videos) with required 'd' tag for unique identification and optional 'origin' tag for tracking imported content.

01.md

@@ -85,7 +85,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
 
 ### Kinds
 
-Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications.
+Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. [NIP-10](10.md), for instance, specifies the `kind:1` text note for social media applications.  
 
 This NIP defines one basic kind:
 
@@ -170,9 +170,8 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
   * `["OK", "b1a649ebe8...", false, "pow: difficulty 26 is less than 30"]`
   * `["OK", "b1a649ebe8...", false, "restricted: not allowed to write."]`
   * `["OK", "b1a649ebe8...", false, "error: could not connect to the database"]`
-  * `["OK", "b1a649ebe8...", false, "mute: no one was listening to your ephemeral event and it wasn't handled in any way, it was ignored"]`
 - `CLOSED` messages MUST be sent in response to a `REQ` when the relay refuses to fulfill it. It can also be sent when a relay decides to kill a subscription on its side before a client has disconnected or sent a `CLOSE`. This message uses the same pattern of `OK` messages with the machine-readable prefix and human-readable message. Some examples:
   * `["CLOSED", "sub1", "unsupported: filter contains unknown elements"]`
   * `["CLOSED", "sub1", "error: could not connect to the database"]`
   * `["CLOSED", "sub1", "error: shutting down idle subscription"]`
-- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, `mute` and `error` for when none of that fits.
+- The standardized machine-readable prefixes for `OK` and `CLOSED` are: `duplicate`, `pow`, `blocked`, `rate-limited`, `invalid`, `restricted`, and `error` for when none of that fits.

29.md

@@ -20,7 +20,7 @@ Relays are supposed to generate the events that describe group metadata and grou
 
 ## Group identifier
 
-A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
+A group must be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
 
 Group identifiers must be strings restricted to the characters `a-z0-9-_`, and SHOULD be random in order to avoid name collisions.
 
@@ -30,6 +30,10 @@ When encountering just the `<host>` without the `'<group-id>`, clients MAY infer
 
 Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
 
+## Protected events
+
+Events sent to a group MAY include the [NIP-70](70.md) `-` tag to mark them as protected events. This ensures that group messages can only be published to the intended relay by their original authors, preventing unauthorized republishing to other relays and maintaining the integrity of group discussions within their designated relay. This provides an alternative or additional method to timeline references for keeping group messages from being taken out of context.
+
 ## Timeline references
 
 In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
@@ -154,13 +158,14 @@ When this event is not found, clients may still connect to the group, but treat
     ["picture", "https://pizza.com/pizza.png"],
     ["about", "a group for people who love pizza"],
     ["public"], // or ["private"]
-    ["open"] // or ["closed"]
+    ["open"], // or ["closed"]
+    ["original_relay", "wss://original.relay.com"] // optional: original relay where group was created
   ]
   // other fields...
 }
 ```
 
-`name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
+`name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled. `original_relay` (optional) indicates the relay where the group was originally created, allowing clients to track the group's origin even when it has been forked to other relays.
 
 - *group admins* (`kind:39001`) (optional)
 

34.md

@@ -163,7 +163,7 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
 
 The most recent Status event (by `created_at` date) from either the issue/patch author or a maintainer is considered valid.
 
-The Status of a patch-revision is to either that of the root-patch, or `1632` (_Closed_) if the root-patch's Status is `1631` (_Applied/Merged_) and the patch-revision isn't tagged in the `1631` (_Applied/Merged_) event.
+The Status of a patch-revision defaults to either that of the root-patch, or `1632` (_Closed_) if the root-patch's Status is `1631` (_Applied/Merged_) and the patch-revision isn't tagged in the `1631` (_Applied/Merged_) event.
 
 
 ## Possible things to be added later

51.md

@@ -32,7 +32,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                                              |
 | Search relays     | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                                              |
 | Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
-| Relay feeds       | 10012 | user favorite browsable relays (and relay sets)             | `"relay"` (relay URLs) and `"a"` (kind:30002 relay set)                                             |
+| Favorite relays   | 10012 | user favorite relays and pointers to relay sets             | `"relay"` (relay URLs) and `"a"` (kind:30002 relay set)                                             |
 | Interests         | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                                                |
 | Media follows     | 10020 | multimedia (photos, short video) follow list                | `"p"` (pubkeys -- with optional relay hint and petname)                                             |
 | Emojis            | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                                    |

69.md

@@ -80,7 +80,6 @@ Currently implemented on the following platforms:
 - [Mostro](https://github.com/MostroP2P/mostro)
 - [@lnp2pBot](https://github.com/lnp2pBot/bot)
 - [Robosats](https://github.com/RoboSats/robosats/pull/1362)
-- [Peach Bitcoin](https://github.com/Peach2Peach/peach-nostr-announcer-bot)
 
 ## References
 

71.md

@@ -20,6 +20,20 @@ Nothing except cavaliership and common sense prevents a _short_ video from being
 
 The format uses a _regular event_ kind `21` for _normal_ videos and `22` for _short_ videos.
 
+## Addressable Video Events
+
+For content that may need updates after publication (such as correcting metadata, descriptions, or handling URL migrations), addressable versions are available:
+
+- Kind `34235` for _addressable normal videos_
+- Kind `34236` for _addressable short videos_
+
+These addressable events follow the same format as their regular counterparts but include a `d` tag as a unique identifier and can be updated while maintaining the same addressable reference. This is particularly useful for:
+
+- Metadata corrections (descriptions, titles, tags) without republishing
+- Preservation of imported content IDs from legacy platforms
+- URL migration when hosting changes
+- Platform migration tracking
+
 The `.content` of these events is a summary or description on the video content.
 
 The primary source of video information is the `imeta` tags which is defined in [NIP-92](92.md)
@@ -71,6 +85,9 @@ The `image` tag contains a preview image (at the same resolution). Multiple `ima
 
 Additionally `service nip96` may be included to allow clients to search the authors NIP-96 server list to find the file using the hash.
 
+### Required tags for addressable events:
+* `d` - Unique identifier for this video (user-chosen string, required for kinds 34235, 34236)
+
 ### Other tags:
 * `title` (required) title of the video
 * `published_at`, for the timestamp in unix seconds (stringified) of the first time the video was published
@@ -83,6 +100,9 @@ Additionally `service nip96` may be included to allow clients to search the auth
 * `p` (optional, repeated) 32-bytes hex pubkey of a participant in the video, optional recommended relay URL
 * `r` (optional, repeated) references / links to web pages
 
+### Optional tags for imported content:
+* `origin` - Track original platform and ID: `["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"]`
+
 ```jsonc
 {
   "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
@@ -127,3 +147,56 @@ Additionally `service nip96` may be included to allow clients to search the auth
   ]
 }
 ```
+
+## Addressable Event Example
+
+```jsonc
+{
+  "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
+  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
+  "created_at": <Unix timestamp in seconds>,
+  "kind": 34235 | 34236,
+  "content": "<summary / description of video>",
+  "tags": [
+    ["d", "<unique-identifier>"],
+    ["title", "<title of video>"],
+    ["published_at", "<unix timestamp>"],
+    ["alt", "<description for accessibility>"],
+
+    // video data
+    ["imeta",
+      "url https://example.com/media.mp4",
+      "m video/mp4",
+      "dim 480x480",
+      "blurhash eVF$^OI:${M{%LRjWBoLoLaeR*",
+      "image https://example.com/thumb.jpg",
+      "x 3093509d1e0bc604ff60cb9286f4cd7c781553bc8991937befaacfdc28ec5cdc"
+    ],
+
+    ["duration", <duration in seconds>],
+    ["content-warning", "<reason>"],
+
+    // origin tracking for imported content
+    ["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"],
+
+    // participants
+    ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
+
+    // hashtags
+    ["t", "<tag>"],
+    ["t", "<tag>"],
+
+    // reference links
+    ["r", "<url>"]
+  ]
+}
+```
+
+## Referencing Addressable Events
+
+To reference an addressable video:
+
+```
+["a", "34235:<pubkey>:<d-tag-value>", "<relay-url>"]  // for normal videos
+["a", "34236:<pubkey>:<d-tag-value>", "<relay-url>"]  // for short videos
+```

72.md

@@ -41,55 +41,19 @@ The goal of this NIP is to enable public communities. It defines the replaceable
 
 # Posting to a community
 
-[NIP-22](NIP-22) kind 1111 events SHOULD be used for text notes posted to a community, with the `A` tag always scoped to the community definition.
-
-## Top-level posts
-
-For top-level posts, the uppercase and lowercase NIP-22 tags should both refer to the community definition itself.
+Any Nostr event can be posted to a community. Clients MUST add one or more community `a` tags, each with a recommended relay.
 
 ```jsonc
 {
-  "kind": 1111,
+  "kind": 1,
   "tags": [
-    ["A", "34550:<community-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
-    ["a", "34550:<community-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
-    ["P", "<community-author-pubkey>", "<optional-relay-url>"],
-    ["p", "<community-author-pubkey>", "<optional-relay-url>"],
-    ["K", "34550"],
-    ["k", "34550"],
+    ["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
   ],
-  "content": "Hi everyone. It's great to be here!",
+  "content": "hello world",
   // other fields...
 }
 ```
 
-## Nested replies
-
-For nested replies, the uppercase tags should still refer to the community definition, while the lowercase tags should refer to the parent post or reply.
-
-```jsonc
-{
-  "kind": 1111,
-  "tags": [
-    // community definition itself
-    ["A", "34550:<community-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
-    ["P", "<community-author-pubkey>", "<optional-relay-url>"],
-    ["K", "34550"],
-
-    // parent post or reply
-    ["e", "<parent-event-id>", "<optional-relay-url>"],
-    ["p", "<parent-event-author-pubkey>", "<optional-relay-url>"],
-    ["k", "<parent-event-kind>"] // most likely "1111"
-  ],
-  "content": "Agreed! Welcome everyone!",
-  // other fields...
-}
-```
-
-## Backwards compatibility note
-
-Previously kind 1 events were used for posts in communities, with an "a" tag pointing to the community. For backwards compatibility, clients MAY still query for kind 1 events, but SHOULD NOT use them for new posts. Instead, clients SHOULD use kind 1111 events with the `A` and `a` tags as described above.
-
 # Moderation
 
 Anyone may issue an approval event to express their opinion that a post is appropriate for a community. Clients MAY choose which approval events to honor, but SHOULD at least use ones published by the group's defined moderators.

73.md

@@ -20,7 +20,6 @@ There are certain established global content identifiers such as [Book ISBNs](ht
 | Geohashes              | "geo:`<geohash, lowercase>`"                               | "geo"                    |
 | Movies                 | "isan:`<id, without version part>`"                        | "isan"                   |
 | Papers                 | "doi:`<id, lowercase>`"                                    | "doi"                    |
-| Music pieces           | "isrc:`<id, uppercase>`"                                   | "isrc"                    |
 | Hashtags               | "#`<topic, lowercase>`"                                    | "#"                      |
 | Podcast Feeds          | "podcast:guid:`<guid>`"                                    | "podcast:guid"           |
 | Podcast Episodes       | "podcast:item:guid:`<guid>`"                               | "podcast:item:guid"      |

87.md

@@ -1,142 +0,0 @@
-NIP-87
-======
-
-Ecash Mint Discoverability
---------------------------------
-
-`draft` `optional`
-
-This NIP describes `kind:38173`, `kind:38172` and `kind:38000`: a way to discover ecash mints, their capabilities, and people who recommend them.
-
-## Rationale
-
-Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics.
-This NIP provides a simple way for users to discover ecash mints recommended by other users and to interact with them.
-
-### Parties involved
-
-There are three actors to this workflow:
-
-* An ecash mint operator, announces their mint and its capabilities.
-    * Publishes `kind:38173` or `kind:38172`, detailing how to connect to it and its capabilities.
-* user A, who recommends an ecash mint
-    * Publishes `kind:38000`
-* user B, who seeks a recommendation for an ecash mint
-    * Queries for `kind:38000` and, based on results, queries for `kind:38173`/`kind:38172`
-
-## Events
-
-### Recommendation event
-```json
-{
-  "kind": 38000,
-  "pubkey": <recommender-user-pubkey>,
-  "tags": [
-    ["k", "38173"],
-    ["d", "<d-identifier>"],
-    ["u", <recommended-fedimint-invite-code>],
-    ["a", "38173:fedimint-pubkey:<d-identifier>", "wss://relay1"]
-  ],
-  "content": "I trust this mint with my life"
-}
-```
-
-The recommendation event is a parameterized-replacable event so that a user can change edit their recommendation without creating a new event.
-
-The `d` tag in `kind:38000` is the `kind:38173`/`kind:38172` event identifier this event is recommending, if no event exists, the `d` tag can still be calculated from the mint's pubkey/id.
-The `k` tag is the kind number that corresponds to the event kind that the user is recommending, in this case `kind:38173` for fedimints and `kind:38172` for cashu mints.
-
-Optional `u` tags can be added to give a recommend way to connect to the mint.
-The value of the tag is the URL or invite code of the ecash mint.
-Multiple `u` tags can appear on the same `kind:38000`.
-
-`a` tags are used to point to the `kind:38173`/`kind:38172` event of the ecash mint.
-The first value of the tag is the `kind:38173`/`kind:38172` event identifier, the second value of the tag is a relay hint.
-This is used to correctly point to the mint's `kind:38173`/`kind:38172` event in case there are duplicates claiming to be the same mint.
-
-The content can be used to give a review.
-
-## Ecash Mint Information
-
-Cashu mints SHOULD publish `kind:38172` events to announce their capabilities and how to connect to them.
-
-For cashu mints, the `u` tag SHOULD be the URL to the cashu mint and it should list the nuts that the cashu mint supports.
-
-The `d` tag SHOULD be the mint's pubkey (found when querying `/v1/info`), this way users can query by pubkey and find the mint announcement.
-
-An `n` tag SHOULD be added to signify the network the cashu mint is on (either `mainnet`, `testnet`, `signet`, or `regtest`)
-
-```json
-{
-  "kind": 38172,
-  "pubkey": "<application-pubkey>",
-  "content": "<optional-kind:0-style-metadata>",
-  "tags": [
-    ["d", <cashu mint pubkey>],
-    ["u", "https://cashu.example.com"],
-    ["nuts", "1,2,3,4,5,6,7"],
-    ["n", "mainnet"]
-  ]
-}
-```
-
-Fedimints SHOULD publish `kind:38173` events to announce their capabilities and how to connect to them.
-
-For fedimints, it should list all known fedimint invite codes in `u` tags and it should list the modules it supports.
-
-The `d` tag SHOULD be the federation id, this way users can query by federation id and find the fedimint announcement.
-
-An `n` tag SHOULD be added to signify the network the fedimint is on (either `mainnet`, `testnet`, `signet`, or `regtest`)
-
-```json
-{
-  "kind": 38173,
-  "pubkey": "<application-pubkey>",
-  "content": "<optional-kind:0-style-metadata>",
-  "tags": [
-    ["d", <federation-id>],
-    ["u", "fed11abc.."],
-    ["u", "fed11xyz.."],
-    ["modules", "lightning,wallet,mint"],
-    ["n", "signet"]
-  ]
-}
-```
-
-* `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:38173` is not a normal user. If `content` is empty, the `kind:0` of the pubkey should be used to display mint information (e.g. name, picture, web, LUD16, etc.)
-
-## Example
-
-### User A recommends some mints
-User A might be a user of a cashu mint. Using a client, user A publishes an event recommending the cashu mint they use.
-
-```json
-{
-  "kind": 38000,
-  "tags": [
-    ["u", "fed11abc..", "fedimint"],
-    ["u", "https://cashu.example.com", "cashu"],
-    ["a", "38173:fedimint-pubkey:<d-identifier>", "wss://relay1", "fedimint"],
-    ["a", "38172:cashu-mint-pubkey:<d-identifier>", "wss://relay2", "cashu"]
-  ],
-  ...
-}
-```
-
-### User B finds a mint
-User B wants to use an ecash wallet, they need to find a mint.
-
-User B's wallet client queries for `kind:38000` events, looking for recommendations for ecash mints.
-
-```json
-["REQ", <id>, [{ "kinds": [38000], "authors": [<user>, <users-contact-list>], "#k": ["38173"] }]]
-```
-
-User B, who follows User A, sees that `kind:38000` event and tries to connect to the corresponding mints.
-
-### Alternative query bypassing `kind:38000`
-Alternatively, users might choose to query directly for `kind:38173` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms or querying high-quality restricted relays to avoid directing users to malicious handlers.
-
-```json
-["REQ", <id>, [{ "kinds": [38173], "authors": [...] }]]
-```

99.md

@@ -8,7 +8,7 @@ Classified Listings
 
 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 specification supports a broad range of use cases physical goods, services, work opportunities, rentals, free giveaways, personals, etc. To promote interoperability between clients implementing NIP-99 for e-commerce, you can find the extension proposal [here](https://github.com/GammaMarkets/market-spec/blob/main/spec.md) which standardizes the e-commerce use case while maintaining the specification's lightweight and flexible nature. While [NIP-15](15.md) provides a strictly structured marketplace specification, NIP-99 has emerged as a simpler and more flexible alternative.
+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.
 
 The structure of these events is very similar to [NIP-23](23.md) long-form content events.
 

F3.md

@@ -1,48 +0,0 @@
-NIP-F3
-======
-
-Scrobbling
-----------
-
-`draft` `optional`
-
-This NIP defines `kind:1073` as a _scrobble_ event. It has the following format:
-
-```yaml
-{
-  "kind": 1073,
-  "tags": [
-    ["i", "isrc:<code>"],
-    ["title", "<song title>"],
-    ["album", "<song album>", "<optional variant>"],
-    ["artist", "<musician or band>", "<optional variant>"]
-  ]
-  // other fields...
-}
-```
-
-### Metadata
-
-`"title"`, `"album"` and `"artist"` should always be included, but in case the ISRC code is also included (as it should unless it's too impossible) ISRC can be seen as the authoritative source for all metadata related to the given song, the other tags being just hints.
-
-### Relays
-
-Scrobbles should be published to the author's "write" relays (as per [NIP-65](65.md)).
-
-### Usage
-
-Given that Nostr is open it makes no sense to speak of a _global_ "most listened" tracks, for example, as _last.fm_ does.
-
-It does make sense, however, for clients to display the "most listened" and other stats in the context of individual relays or groups of relays, as long as such relays are gated to a certain community or trusted to not have sybils or spam.
-
-It also makes sense to display data such as "most listened by your friends", "most listened by friends of friends" and other arbitrary selections.
-
-The same is true for things like a feed of "recently listened" tracks.
-
-#### Commenting on tracks
-
-It makes sense to comment on a track by using a [NIP-22](22.md) with a `"i"` tag containing its ISRC code, as specified in [NIP-73](73.md). That way it's possible to display comments in context with scrobbles on a track page, for example, and whatever else.
-
-#### Correcting History
-
-It shouldn't be hard to "edit" an old scrobble by simply deleting it and creating a new scrobble.

README.md

@@ -93,7 +93,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-7D: Threads](7D.md)
 - [NIP-84: Highlights](84.md)
 - [NIP-86: Relay Management API](86.md)
-- [NIP-87: Ecash Mint Discoverability](87.md)
 - [NIP-88: Polls](88.md)
 - [NIP-89: Recommended Application Handlers](89.md)
 - [NIP-90: Data Vending Machines](90.md)
@@ -108,6 +107,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-C7: Chats](C7.md)
 
 ## Event Kinds
+
 | kind          | description                     | NIP                                    |
 | ------------- | ------------------------------- | -------------------------------------- |
 | `0`           | User Metadata                   | [01](01.md)                            |
@@ -200,7 +200,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
 | `13194`       | Wallet Info                     | [47](47.md)                            |
 | `17375`       | Cashu Wallet Event              | [60](60.md)                            |
-| `17375`       | Ecash Mint Recommendation       | [87](87.md)                            |
 | `21000`       | Lightning Pub RPC               | [Lightning.Pub][lnpub]                 |
 | `22242`       | Client Authentication           | [42](42.md)                            |
 | `23194`       | Wallet Request                  | [47](47.md)                            |
@@ -248,11 +247,11 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31924`       | Calendar                        | [52](52.md)                            |
 | `31925`       | Calendar Event RSVP             | [52](52.md)                            |
 | `31989`       | Handler recommendation          | [89](89.md)                            |
-| `31990`       | Handler information             | [89](89.md)                            |
-| `32267`       | Software Application            |                                        |
+| `31990`       | Handler information             | [89](89.md)                            |                         |
+| `32267`       | Software Application            |                                        |                        |
+| `34235`       | Addressable Video Event         | [71](71.md)                            |
+| `34236`       | Addressable Short Video Event   | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |
-| `38172`       | Cashu Mint Announcement         | [87](87.md)                            |
-| `38173`       | Fedimint Announcement           | [87](87.md)                            |
 | `38383`       | Peer-to-peer Order events       | [69](69.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |
 | `39089`       | Starter packs                   | [51](51.md)                            |