NIP-71: Add addressable video events (kinds 34235, 34236) (#2072)

Co-authored-by: hodlbod <jstaab@protonmail.com>

01.md

@@ -4,7 +4,7 @@ NIP-01
 Basic protocol flow description
 -------------------------------
 
-`draft` `mandatory`
+`draft` `mandatory` `relay`
 
 This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.
 

04.md

@@ -6,7 +6,7 @@ NIP-04
 Encrypted Direct Message
 ------------------------
 
-`final` `unrecommended` `optional`
+`final` `unrecommended` `optional` `relay`
 
 A special event with kind `4`, meaning "encrypted direct message". It is supposed to have the following attributes:
 

09.md

@@ -4,7 +4,7 @@ NIP-09
 Event Deletion Request
 ----------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 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.
 

11.md

@@ -4,7 +4,7 @@ NIP-11
 Relay Information Document
 --------------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes.  This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.
 
@@ -17,6 +17,7 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
   "banner": <a link to an image (e.g. in .jpg, or .png format)>,
   "icon": <a link to an icon (e.g. in .jpg, or .png format>,
   "pubkey": <administrative contact pubkey>,
+  "self": <relay's own pubkey>,
   "contact": <administrative alternate contact>,
   "supported_nips": <a list of NIP numbers supported by the relay>,
   "software": <string identifying relay software URL>,
@@ -60,6 +61,10 @@ An administrative contact may be listed with a `pubkey`, in the same format as N
 
 Relay operators have no obligation to respond to direct messages.
 
+### Self
+
+A relay MAY maintain an identity independent from its administrator using the `self` field, which MUST be a 32-byte hex public key. This allows relays to respond to requests with events published either in advance or on demand by their own key.
+
 ### Contact
 
 An alternative contact may be listed under the `contact` field as well, with the same purpose as `pubkey`.  Use of a Nostr public key and direct message SHOULD be preferred over this.  Contents of this field SHOULD be a URI, using schemes such as `mailto` or `https` to provide users with a means of contact.

13.md

@@ -4,7 +4,7 @@ NIP-13
 Proof of Work
 -------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.
 

17.md

@@ -4,7 +4,7 @@ NIP-17
 Private Direct Messages
 -----------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines an encrypted chat scheme which uses [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps.
 

18.md

@@ -21,9 +21,9 @@ reposted.
 
 ## Quote Reposts
 
-Mentions to [NIP-21](21.md) entities like `nevent`, `note` and `naddr` on any 
+Mentions to [NIP-21](21.md) entities like `nevent`, `note` and `naddr` on any
-event must be converted into `q` tags. The `q` tag ensures quote reposts are 
+event must be converted into `q` tags. The `q` tag ensures quote reposts are
-not pulled and included as replies in threads. It also allows you to easily 
+not pulled and included as replies in threads. It also allows you to easily
 pull and count all of the quotes for a post. The syntax follows
 
 `["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]`
@@ -36,3 +36,10 @@ as a "generic repost", that can include any kind of event inside other than
 
 `kind 16` reposts SHOULD contain a `"k"` tag with the stringified kind number
 of the reposted event as its value.
+
+When reposting a replaceable event, the repost SHOULD include an `"a"` tag with
+the event coordinate (`kind:pubkey:d-tag`) of the reposted event.
+
+If the `"a"` tag is not present, it indicates that a specific version of a replaceable
+event is being reposted, in which case the `content` field must contain the full
+JSON string of the reposted event.

26.md

@@ -6,7 +6,7 @@ NIP-26
 Delegated Event Signing
 -----------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines how events can be delegated so that they can be signed by other keypairs.
 

29.md

@@ -4,7 +4,7 @@ NIP-29
 Relay-based Groups
 ------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
 
@@ -83,7 +83,7 @@ Any user can send a kind `9021` event to the relay in order to request admission
 }
 ```
 
-The optional `code` tag may be used by the relay to preauthorize acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
+The optional `code` tag may be used by the relay to preauthorize acceptance, together with the `kind:9009` `create-invite` moderation event.
 
 - *leave request* (`kind:9022`)
 
@@ -153,14 +153,18 @@ When this event is not found, clients may still connect to the group, but treat
     ["name", "Pizza Lovers"],
     ["picture", "https://pizza.com/pizza.png"],
     ["about", "a group for people who love pizza"],
-    ["public"], // or ["private"]
+    ["private"],
-    ["open"] // or ["closed"]
+    ["closed"]
   ]
   // 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.
+- `private` indicates that only members can _read_ group messages. Omitting this tag indicates that anyone can read group messages.
+- `restricted` indicates that only members can _write_ messages to the group. Omitting this tag indicates that anyone can send messages to the group.
+- `hidden` indicates that relays should hide group metadata from non-members. Omitting this tag indicates that anyone can request group metadata events.
+- `closed` indicates that join requests are ignored. Omitting this tag indicates that users can expect join requests to be honored.
 
 - *group admins* (`kind:39001`) (optional)
 
@@ -231,7 +235,7 @@ The latest of either `kind:9000` or `kind:9001` events present in a group should
 
 ### Adding yourself to a group
 
-When a group is `open`, anyone can send a `kind:9021` event to it in order to be added, then expect a `kind:9000` event to be emitted confirming that the user was added. The same happens with `closed` groups, except in that case a user may only send a `kind:9021` if it has an invite code.
+Anyone can send a `kind:9021` join request to a group. The relay may then generate a `kind:9000` event immediately, or defer that decision to an administator. If a group is `closed`, join requests are not honored unless they include an invite code.
 
 ### Storing your list of groups
 

40.md

@@ -4,7 +4,7 @@ NIP-40
 Expiration Timestamp
 --------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
 

42.md

@@ -4,7 +4,7 @@ NIP-42
 Authentication of clients to relays
 -----------------------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.
 

43.md

@@ -4,7 +4,7 @@ NIP-43
 Relay Access Metadata and Requests
 ----------------------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users.
 

45.md

@@ -4,7 +4,7 @@ NIP-45
 Event Counts
 ------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts.
 

46.md

@@ -204,7 +204,7 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a
 
 ### Announcing _remote-signer_ metadata
 
-_remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
+_remote-signer_ MAY publish its metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
 ```jsonc
 {
     "names":{

50.md

@@ -4,7 +4,7 @@ NIP-50
 Search Capability
 -----------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 ## Abstract
 

51.md

@@ -26,7 +26,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Mute list         | 10000 | things the user doesn't want to see in their feeds          | `"p"` (pubkeys), `"t"` (hashtags), `"word"` (lowercase string), `"e"` (threads)                     |
 | Pinned notes      | 10001 | events the user intends to showcase in their profile page   | `"e"` (kind:1 notes)                                                                                |
 | Read/write relays | 10002 | where a user publishes to and where they expect mentions    | see [NIP-65](65.md)                                                                                 |
-| Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles), `"t"` (hashtags), `"r"` (URLs)                   |
+| Bookmarks         | 10003 | uncategorized, "global" list of things a user wants to save | `"e"` (kind:1 notes), `"a"` (kind:30023 articles)                   |
 | Communities       | 10004 | [NIP-72](72.md) communities the user belongs to             | `"a"` (kind:34550 community definitions)                                                            |
 | Public chats      | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                                                 |
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                                              |
@@ -52,9 +52,10 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | ---                   | ---   | ---                                                                                          | ---                                                                                 |
 | Follow sets           | 30000 | categorized groups of users a client may choose to check out in different circumstances      | `"p"` (pubkeys)                                                                     |
 | Relay sets            | 30002 | user-defined relay groups the user can easily pick and choose from during various operations | `"relay"` (relay URLs)                                                              |
-| 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)   |
+| Bookmark sets         | 30003 | user-defined bookmarks categories , for when bookmarks must be in labeled separate groups    | `"e"` (kind:1 notes), `"a"` (kind:30023 articles)                                   |
 | 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        | `"e"` (kind:21 videos)                                                              |
+| Curation sets         | 30006 | groups of pictures picked by users as interesting and/or belonging to the same category      | `"e"` (kind:20 pictures)                                                            |
 | 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))                                                     |

52.md

@@ -56,7 +56,7 @@ Example:
 
 ```yaml
 {
-  "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
+  "id": <32-bytes lowercase hex-encoded SHA-256 of the serialized event data>,
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": 31922,

54.md

@@ -8,7 +8,7 @@ Wiki
 
 This NIP defines `kind:30818` (an _addressable event_) for 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.
+Articles are identified by lowercase, normalized `d` tags.
 
 ## Articles
 ```json
@@ -16,15 +16,30 @@ Articles are identified by lowercase, normalized ascii `d` tags.
   "content": "A wiki is a hypertext publication collaboratively edited and managed by its own audience.",
   "tags": [
     ["d", "wiki"],
-    ["title", "Wiki"],
+    ["title", "Wiki"]
   ]
 }
 ```
 
 ## `d` tag normalization rules
 
-- Any non-letter character MUST be converted to a `-`.
+- All letters with uppercase/lowercase variants MUST be converted to lowercase.
-- All letters MUST be converted to lowercase.
+- Whitespace MUST be converted to `-`.
+- Punctuation and symbols SHOULD be removed.
+- Multiple consecutive `-` SHOULD be collapsed to a single `-`.
+- Leading and trailing `-` SHOULD be removed.
+- Non-ASCII letters (e.g., Japanese, Chinese, Arabic, Cyrillic) MUST be preserved as UTF-8.
+- Numbers MUST be preserved.
+
+For example:
+- `"Wiki Article"` → `"wiki-article"`
+- `"What's Up?"` → `"whats-up"`
+- `"  Hello  World  "` → `"hello-world"`
+- `"Article 1"` → `"article-1"`
+- `"ウィキペディア"` → `"ウィキペディア"` (Japanese, no case change)
+- `"Ñoño"` → `"ñoño"` (Spanish, lowercased)
+- `"Москва"` → `"москва"` (Russian, lowercased)
+- `"日本語 Article"` → `"日本語-article"` (mixed scripts)
 
 ## Content
 
@@ -32,10 +47,11 @@ The `content` should be Asciidoc with two extra functionalities: **wikilinks** a
 
 Unlike normal Asciidoc links `http://example.com[]` that link to external 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:
+Wikilinks can take these forms:
 
-  1. `[[Target Page]]` -- in this case it will link to the page `target-page` (according to `d` tag normalization rules above) and be displayed as `Target Page`;
+  1. `[[Target Page]]` -- links to `target-page` and displays as `Target Page`;
-  2. `[[target page|see this]]` -- in this case it will link to the page `target-page`, but will be displayed as `see this`.
+  2. `[[target page|see this]]` -- links to `target-page` but displays as `see this`;
+  3. `[[日本語 Topic|Japanese Topic]]` -- links to `日本語-topic` and displays as `Japanese Topic`.
 
 `nostr:...` links, as per [NIP-21](21.md), should link to profiles or arbitrary Nostr events. Although it is not recommended to link to specific versions of articles -- instead the _wikilink_ syntax should be preferred, since it should be left to the reader and their client to decide what version of any given article they want to read.
 

55.md

@@ -107,6 +107,13 @@ Send the Intent:
 launcher.launch(intent)
 ```
 
+### Initiating a connection
+
+- Client send a get_public_key `Intent`
+- Signer responds with the user `pubkey` and it's `packageName`
+- Client saves the `pubkey` and `packageName` somewhere and NEVER calls `get_public_key` again
+- Client now can send `content resolvers` and `Intents` for the other methods
+
 #### Methods
 
 - **get_public_key**
@@ -203,10 +210,10 @@ launcher.launch(intent)
     context.startActivity(intent)
     ```
   - result:
-    - If the user approved intent it will return the **signature** and **id** fields
+    - If the user approved intent it will return the **result** and **id** fields
 
       ```kotlin
-      val encryptedText = intent.data?.getStringExtra("signature")
+      val encryptedText = intent.data?.getStringExtra("result")
       // the id you sent
       val id = intent.data?.getStringExtra("id")
       ```
@@ -299,33 +306,6 @@ Clients SHOULD save the user pubkey locally and avoid calling the `get_public_ke
 
 #### Methods
 
-- **get_public_key**
-  - params:
-
-    ```kotlin
-    val result = context.contentResolver.query(
-        Uri.parse("content://com.example.signer.GET_PUBLIC_KEY"),
-        listOf(hex_pub_key),
-        null,
-        null,
-        null
-    )
-    ```
-  - result:
-    - Will return the **pubkey** in the result column
-
-      ```kotlin
-        if (result == null) return
-
-        if (it.getColumnIndex("rejected") > -1) return
-
-        if (result.moveToFirst()) {
-            val index = it.getColumnIndex("result")
-            if (index < 0) return
-            val pubkey = it.getString(index)
-        }
-      ```
-
 - **sign_event**
   - params:
 

58.md

@@ -11,7 +11,7 @@ user profiles:
 
 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.
+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-transferable.
 
 3. A "Profile Badges" event is defined as an _addressable event_ with kind `30008` with a `d` tag with the value `profile_badges`.
 Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed.

59.md

@@ -4,7 +4,7 @@ NIP-59
 Gift Wrap
 ---------
 
-`optional`
+`optional` `relay`
 
 This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata
 for a given event, perform collaborative signing, and more.
@@ -99,6 +99,8 @@ AUTH, and refuse to serve wrapped events to non-recipients.
 
 When adding expiration tags to both `seal` and `gift wrap` layers, implementations SHOULD use independent random timestamps for each layer. Using different `created_at` values increases timing variance and helps protect against metadata correlation attacks.
 
+Since signing keys are random, relays SHOULD delete `kind 1059` events whose p-tag matches the signer of
+[NIP-09](09.md) deletions or [NIP-62](62.md) vanish requests.
 
 ## An Example
 

62.md

@@ -4,7 +4,7 @@ NIP-62
 Request to Vanish
 -----------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database. 
 

66.md

@@ -4,7 +4,7 @@ NIP-66
 Relay Discovery and Liveness Monitoring
 -------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines events for relay discovery and the announcement of relay monitors.
 
@@ -67,7 +67,7 @@ Tags include:
 - `frequency` - The frequency in seconds at which the monitor publishes events.
 - `timeout` (optional) - The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests.
 - `c` - a lowercase string describing the checks conducted by a monitor. Examples include `open`, `read`, `write`, `auth`, `nip11`, `dns`, and `geo`.
-- `g` - [NIP-52](https://github.com/nostr-protocol/nips/blob/master/11.md) geohash tag
+- `g` - [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash tag
 
 Monitors SHOULD also publish a `kind 0` profile and a `kind 10002` relay selections event.
 

69.md

@@ -41,7 +41,8 @@ Events are [addressable events](01.md#kinds) and use `38383` as event kind, a p2
     ["name", "Nakamoto"],
     ["g", "<geohash>"],
     ["bond", "0"],
-    ["expiration", "1719391096"],
+    ["expires_at", "1719391096"],
+    ["expiration", "1719995896"],
     ["y", "lnp2pbot"],
     ["z", "order"]
   ],
@@ -55,7 +56,7 @@ Events are [addressable events](01.md#kinds) and use `38383` as event kind, a p2
 - `d` < Order ID >: A unique identifier for the order.
 - `k` < Order type >: `sell` or `buy`.
 - `f` < Currency >: The asset being traded, using the [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217) standard.
-- `s` < Status >: `pending`, `canceled`, `in-progress`, `success`.
+- `s` < Status >: `pending`, `canceled`, `in-progress`, `success`, `expired`.
 - `amt` < Amount >: The amount of Bitcoin to be traded, the amount is defined in satoshis, if `0` means that the amount of satoshis will be obtained from a public API after the taker accepts the order.
 - `fa` < Fiat amount >: The fiat amount being traded, for range orders two values are expected, the minimum and maximum amount.
 - `pm` < Payment method >: The payment method used for the trade, if the order has multiple payment methods, they should be separated by a comma.
@@ -67,7 +68,8 @@ Events are [addressable events](01.md#kinds) and use `38383` as event kind, a p2
 - `name` [Name]: The name of the maker.
 - `g` [Geohash]: The geohash of the operation, it can be useful in a face to face trade.
 - `bond` [Bond]: The bond amount, the bond is a security deposit that both parties must pay.
-- `expiration` < Expiration\>: The expiration date of the order ([NIP-40](40.md)).
+- `expires_at` < Expires At\>: The expiration date of the event being published in `pending` status, after this time the event status SHOULD be changed to `expired`.
+- `expiration` < Expiration\>: The expiration date of the event, after this time the relay SHOULD delete it ([NIP-40](40.md)).
 - `y` < Platform >: The platform that created the order.
 - `z` < Document >: `order`.
 

70.md

@@ -4,7 +4,7 @@ NIP-70
 Protected Events
 ----------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 When the `"-"` tag is present, that means the event is "protected".
 

71.md

@@ -20,13 +20,27 @@ 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)
 
 Each `imeta` tag can be used to specify a variant of the video by the `dim` & `m` properties.
 
-This NIP defines the following additional `imeta` properties aside form those listen in [NIP-92](92.md) & [NIP-94](94.md):
+This NIP defines the following additional `imeta` properties aside from those listed in [NIP-92](92.md) & [NIP-94](94.md):
 
 * `duration` (recommended) the duration of the video/audio in seconds (floating point number)
 * `bitrate` (recommended) the average bitrate of the video/audio in bits/sec
@@ -81,6 +95,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
@@ -92,6 +109,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>",
@@ -135,3 +155,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,7 +41,7 @@ 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.
+[NIP-22](22.md) 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
 

77.md

@@ -4,7 +4,7 @@ NIP-77
 Negentropy Syncing
 ------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This document describes a protocol extension for syncing events. It works for both client-relay and relay-relay scenarios. If both sides of the sync have events in common, then this protocol will use less bandwidth than transferring the full set of events (or even just their IDs).
 

88.md

@@ -48,7 +48,7 @@ Example Event
 
 The response event is a `kind:1018` event. It contains an e tag with the poll event it is referencing, followed by one or more response tags.
 
-- **response** : The tag contains "response" as it's first positional argument followed by the option Id selected.
+- **response** : The tag contains "response" as its first positional argument followed by the option Id selected.
 
 The responses are meant to be published to the relays specified in the poll event.
 

90.md

@@ -58,7 +58,7 @@ All tags are optional.
     * `<input-type>`: The way this argument should be interpreted. MUST be one of:
         * `url`: A URL to be fetched of the data that should be processed.
         * `event`: A Nostr event ID.
-        * `job`: The output of a previous job with the specified event ID. The dermination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.)
+        * `job`: The output of a previous job with the specified event ID. The determination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.)
         * `text`: `<data>` is the value of the input, no resolution is needed
     * `<relay>`: If `event` or `job` input-type, the relay where the event/job was published, otherwise optional or empty string
     * `<marker>`: An optional field indicating how this input should be used within the context of the job

A4.md

@@ -0,0 +1,56 @@
+NIP-A4
+======
+
+Public Messages
+---------------
+
+`draft` `optional`
+
+This NIP defines kind `24` as a simple plaintext message to one or more Nostr users. 
+
+The `.content` contains the message. `p` tags identify one or more receivers.
+
+```jsonc
+{
+  "pubkey": "<sender-pubkey>",
+  "kind": 24,
+  "tags": [
+    ["p", "<receiver>", "<relay-url>"],
+  ],
+  "content": "<message-in-plain-text>",
+}
+```
+
+Messages MUST be sent to the [NIP-65](65.md) inbox relays of each receiver and the outbox relay of the sender.
+
+Kind `24` is designed to be shown and replied to from notification screens. The goal is to allow clients to 
+support this feature without having to worry about chat history. There are no message chains. The concept of a 
+"thread", a "thread root", or a "chatroom" does not exist in this system, as messages can start and continue 
+without any syntactic connection to each other. `e` tags must not be used.
+
+This kind is not designed to be displayed on feeds, but anyone can see and reply to messages that may not be for them.
+
+## Advanced Support
+
+[NIP-40](40.md) `expiration` tags are recommended. Since there is no concept of a chatroom, it is unlikely that these messages will 
+make sense as time goes on.
+
+[NIP-18](18.md) quote repost `q` tags MAY be used when citing events in the `.content` with [NIP-21](21.md).
+
+```json
+["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]
+```
+
+[NIP-25](25.md) reactions MUST add a `k` tag to `24`. 
+
+[NIP-57](57.md) zaps MUST include the `k` tag to `24`
+
+[NIP-21](21.md) links that use [NIP-19](19.md)'s `nevent1` MUST include a `kind` of `24`. Links that are not `kind:24` are not expected to be rendered natively by the client.
+
+[NIP-92](92.md) `imeta` tags SHOULD be added for image and video links.
+
+## Warnings
+
+There MUST be no expectation of privacy in this kind. It is just a public reply, but without a root note.
+
+Avoid confusing this kind with Kind `14` rumors in [NIP-17](17.md) DMs. This kind is signed and designed for public consumption.

BE.md

@@ -0,0 +1,137 @@
+NIP-BE
+======
+
+Nostr BLE Communications Protocol
+---------------------------------
+
+`draft` `optional`
+
+This NIP specifies how Nostr apps can use BLE to communicate and synchronize with each other. The BLE protocol follows a client-server pattern, so this NIP emulates the WS structure in a similar way, but with some adaptations to its limitations.
+
+## Device advertisement
+A device advertises itself with:
+- Service UUID: `0000180f-0000-1000-8000-00805f9b34fb`
+- Data: Device UUID in ByteArray format
+
+## GATT service
+The device exposes a Nordic UART Service with the following characteristics:
+
+1. Write Characteristic
+   - UUID: `87654321-0000-1000-8000-00805f9b34fb`
+   - Properties: Write
+
+2. Read Characteristic
+   - UUID: `12345678-0000-1000-8000-00805f9b34fb`
+   - Properties: Notify, Read
+
+## Role assignment
+
+When one device initially finds another advertising the service, it will read the service's data to get the device UUID and compare it with its own advertised device UUID. For this communication, the device with the highest ID will take the role of GATT Server (Relay), the other will be considered the GATT Client (Client) and will proceed to establish the connection.
+
+For devices whose purpose will require a single role, its device UUID will always be:
+
+- GATT Server: `FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF`
+- GATT Client: `00000000-0000-0000-0000-000000000000`
+
+## Messages
+
+All messages will follow [NIP-01](/01.md) message structure. For a given message, a compression stream (DEFLATE) is applied to the message to generate a byte array. Depending on the BLE version, the byte array can be too large for a single message (20-23 bytes in BLE 4.2, 256 bytes in BLE > 4.2). In that case, this byte array is split into any number of batches following the structure:
+
+```
+[batch index (first 2 bytes)][batch n][is last batch (last byte)]
+```
+After reception of all batches, the other device can then join them and decompress. To ensure reliability, only 1 message will be read/written at a time. MTU can be negotiated in advance. The maximum size for a message is 64KB; bigger messages will be rejected.
+
+## Examples
+
+This example implements a function to split and compress a byte array into chunks, as well as another function to join and decompress them in order to obtain the initial result:
+
+```kotlin
+fun splitInChunks(message: ByteArray): Array<ByteArray> {
+   val chunkSize = 500 // define the chunk size
+   var byteArray = compressByteArray(message)
+   val numChunks = (byteArray.size + chunkSize - 1) / chunkSize // calculate the number of chunks
+   var chunkIndex = 0
+   val chunks = Array(numChunks) { ByteArray(0) }
+
+   for (i in 0 until numChunks) {
+         val start = i * chunkSize
+         val end = minOf((i + 1) * chunkSize, byteArray.size)
+         val chunk = byteArray.copyOfRange(start, end)
+
+         // add chunk index to the first 2 bytes and last chunk flag to the last byte
+         val chunkWithIndex = ByteArray(chunk.size + 2)
+         chunkWithIndex[0] = chunkIndex.toByte() // chunk index
+         chunk.copyInto(chunkWithIndex, 1)
+         chunkWithIndex[chunkWithIndex.size - 1] = numChunks.toByte()
+
+         // store the chunk in the array
+         chunks[i] = chunkWithIndex
+
+         chunkIndex++
+   }
+
+   return chunks
+}
+
+fun joinChunks(chunks: Array<ByteArray>): ByteArray {
+   val sortedChunks = chunks.sortedBy { it[0] }
+   var reassembledByteArray = ByteArray(0)
+   for (chunk in sortedChunks) {
+         val chunkData = chunk.copyOfRange(1, chunk.size - 1)
+         reassembledByteArray = reassembledByteArray.copyOf(reassembledByteArray.size + chunkData.size)
+         chunkData.copyInto(reassembledByteArray, reassembledByteArray.size - chunkData.size)
+   }
+
+   return decompressByteArray(reassembledByteArray)
+}
+
+```
+
+## Workflows
+
+### Client to relay
+
+- Any message the client wants to send to a relay will be a write message.
+- Any message the client receives from a relay will be a read message.
+
+### Relay to client
+
+The relay should notify the client about any new event matching subscription's filters by using the Notify action of the Read Characteristic. After that, the client can proceed to read messages from the relay.
+
+### Device synchronization
+
+Given the nature of BLE, it is expected that the direct connection between two devices might be extremely intermittent, with gaps of hours or even days. That's why it's crucial to define a synchronization process by following [NIP-77](./77.md) but with an adaptation to the limitations of the technology.
+
+After two devices have successfully connected and established the Client-Server roles, the devices will use half-duplex communication to intermittently send and receive messages.
+
+#### Half-duplex synchronization
+
+Right after the 2 devices connect, the Client starts the workflow by sending the first message.
+
+1. Client - Writes ["NEG-OPEN"](/77.md#initial-message-client-to-relay) message.
+2. Server - Sends `write-success`.
+3. Client - Sends `read-message`.
+4. Server - Responds with ["NEG-MSG"](./77.md#subsequent-messages-bidirectional) message.
+5. Client -
+   1. If the Client has messages missing on the Server, it writes one `EVENT`.
+   2. If the Client doesn't have any messages missing on the Server, it writes `EOSE`. In this case, subsequent messages to the Server will be empty while the Server claims to have more notes for the Client.
+6. Server - Sends `write-success`.
+7. Client - Sends `read-message`.
+8. Server -
+   1. If the Server has messages missing on the Client, it responds with one `EVENT`.
+   2. If the Client doesn't have any messages missing on the Server, it responds with `EOSE`. In this case, subsequent responses to the Client will be empty.
+9. If the Client detects that the devices are not synchronized yet, jump to step 5.
+10. After the two devices detect that there are no more missing events on both ends, the workflow will pause at this point.
+
+#### Half-duplex event spread
+
+While two devices are connected and synchronized, it might happen that one of them receives a new message from another connected peer. Devices MUST keep track of which notes have been sent to its peers while they are connected. If the newly received event is detected as missing in one of the connected and synchronized peers:
+
+1. If the peer is a Server:
+   1. Client - It writes the `EVENT`.
+   2. Server - Sends `write-success`.
+2. If the peer is a Client:
+   1. Server - It will send an empty notification to the Client.
+   2. Client - Sends `read-message`.
+   3. Server - Responds with the `EVENT`.

C0.md

@@ -23,9 +23,9 @@ The `.content` field contains the actual code snippet text.
 - `extension` - File extension (without the dot). Examples: "js", "py", "rs"
 - `description` - Brief description of what the code does
 - `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
-- `license` - License under which the code is shared (e.g., "MIT", "GPL-3.0", "Apache-2.0")
+- `license` - License under which the code (along with any related data contained within the event, when available, such as the description) is shared. This MUST be a standard [SPDX](https://spdx.org/licenses/) short identifier (e.g., "MIT", "GPL-3.0-or-later", "Apache-2.0") when available. An additional parameter containing a reference to the actual text of the license MAY be provided. This tag can be repeated, to indicate multi-licensing, allowing recipients to use the code under any license of choosing among the referenced ones
 - `dep` - Dependency required for the code to run (can be repeated)
-- `repo` - Reference to a repository where this code originates
+- `repo` - Reference to a repository where this code originates. This MUST be either a standard URL or, alternatively, the address of a [NIP-34](34.md) Git repository announcement event in the form `"30617:<32-bytes hex a pubkey>:<d tag value>"`. If a repository announcement is referenced, a recommended relay URL where to find the event should be provided as an additional parameter
 
 ## Format
 

EE.md

@@ -1,8 +1,12 @@
-# NIP-EE
+> __Warning__  `unrecommended`: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
 
-## E2EE Messaging using the Messaging Layer Security (MLS) Protocol
+NIP-EE
+======
 
-`draft` `optional`
+E2EE Messaging using the Messaging Layer Security (MLS) Protocol
+----------------------------------------------------------------
+
+`final` `unrecommended` `optional`
 
 This NIP standardizes how to use the [MLS Protocol](https://www.rfc-editor.org/rfc/rfc9420.html) with Nostr for efficient and E2EE (end-to-end encrypted) direct and group messaging.
 

README.md

@@ -103,11 +103,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
 - [NIP-A0: Voice Messages](A0.md)
+- [NIP-A4: Public Messages](A4.md)
 - [NIP-B0: Web Bookmarks](B0.md)
 - [NIP-B7: Blossom](B7.md)
+- [NIP-BE: Nostr BLE Communications Protocol](BE.md)
 - [NIP-C0: Code Snippets](C0.md)
 - [NIP-C7: Chats](C7.md)
-- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md)
+- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md) --- **unrecommended**: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
 
 ## Event Kinds
 | kind          | description                     | NIP                                    |
@@ -133,10 +135,11 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `20`          | Picture                         | [68](68.md)                            |
 | `21`          | Video Event                     | [71](71.md)                            |
 | `22`          | Short-form Portrait Video Event | [71](71.md)                            |
+| `24`          | Public Message                  | [A4](A4.md)                            |
 | `30`          | internal reference              | [NKBIP-03]                             |
-| `31`          | external web reference          | [NKBIP-03]                            |
+| `31`          | external web reference          | [NKBIP-03]                             |
-| `32`          | hardcopy reference              | [NKBIP-03]                            |
+| `32`          | hardcopy reference              | [NKBIP-03]                             |
-| `33`          | prompt reference                | [NKBIP-03]                            |
+| `33`          | prompt reference                | [NKBIP-03]                             |
 | `40`          | Channel Creation                | [28](28.md)                            |
 | `41`          | Channel Metadata                | [28](28.md)                            |
 | `42`          | Channel Message                 | [28](28.md)                            |
@@ -144,9 +147,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `44`          | Channel Mute User               | [28](28.md)                            |
 | `62`          | Request to Vanish               | [62](62.md)                            |
 | `64`          | Chess (PGN)                     | [64](64.md)                            |
-| `443`         | KeyPackage                      | [EE](EE.md)                            |
+| `443`         | KeyPackage                      | [Marmot](marmot)                       |
-| `444`         | Welcome Message                 | [EE](EE.md)                            |
+| `444`         | Welcome Message                 | [Marmot](marmot)                       |
-| `445`         | Group Event                     | [EE](EE.md)                            |
+| `445`         | Group Event                     | [Marmot](marmot)                       |
 | `818`         | Merge Requests                  | [54](54.md)                            |
 | `1018`        | Poll Response                   | [88](88.md)                            |
 | `1021`        | Bid                             | [15](15.md)                            |
@@ -208,7 +211,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10020`       | Media follows                   | [51](51.md)                            |
 | `10030`       | User emoji list                 | [51](51.md)                            |
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
-| `10051`       | KeyPackage Relays List          | [EE](EE.md)                            |
+| `10051`       | KeyPackage Relays List          | [Marmot](marmot)                       |
 | `10063`       | User server list                | [Blossom][blossom]                     |
 | `10096`       | File storage server list        | [96](96.md) (deprecated)               |
 | `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
@@ -217,6 +220,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `11111`       | Transport Method Announcement   | [Nostr Epoxy][nostr-epoxy]             |
 | `13194`       | Wallet Info                     | [47](47.md)                            |
 | `13534`       | Membership Lists                | [43](43.md)                            |
+| `14388`       | User Sound Effect Lists         | [Corny Chat][cornychat-usersoundlist]  |
 | `17375`       | Cashu Wallet Event              | [60](60.md)                            |
 | `21000`       | Lightning Pub RPC               | [Lightning.Pub][lnpub]                 |
 | `22242`       | Client Authentication           | [42](42.md)                            |
@@ -234,6 +238,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30003`       | Bookmark sets                   | [51](51.md)                            |
 | `30004`       | Curation sets                   | [51](51.md)                            |
 | `30005`       | Video sets                      | [51](51.md)                            |
+| `30006`       | Picture sets                    | [51](51.md)                            |
 | `30007`       | Kind mute sets                  | [51](51.md)                            |
 | `30008`       | Profile Badges                  | [58](58.md)                            |
 | `30009`       | Badge Definition                | [58](58.md)                            |
@@ -272,6 +277,11 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31989`       | Handler recommendation          | [89](89.md)                            |
 | `31990`       | Handler information             | [89](89.md)                            |
 | `32267`       | Software Application            |                                        |
+| `32388`       | User Room Favorites             | [Corny Chat][cornychat-roomfavorites]  |
+| `33388`       | High Scores                     | [Corny Chat][cornychat-highscores]     |
+| `34235`       | Addressable Video Event         | [71](71.md)                            |
+| `34236`       | Addressable Short Video Event   | [71](71.md)                            |
+| `34388`       | Sound Effects                   | [Corny Chat][cornychat-soundeffects]   |
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38172`       | Cashu Mint Announcement         | [87](87.md)                            |
 | `38173`       | Fedimint Announcement           | [87](87.md)                            |
@@ -285,8 +295,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
 [lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
+[cornychat-usersoundlist]: https://cornychat.com/datatypes#kind14388usersoundeffectslist
 [cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
 [cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
+[cornychat-roomfavorites]: https://cornychat.com/datatypes#kind32388roomfavorites
+[cornychat-highscores]: https://cornychat.com/datatypes#kind33388highscores
+[cornychat-soundeffects]: https://cornychat.com/datatypes#kind34388soundeffectsets
 [joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
 [NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
 [NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
@@ -295,6 +309,8 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 [Tidal-nostr]: https://wikistr.com/tidal-nostr
 [geocaching]: https://nostrhub.io/naddr1qvzqqqrcvypzppscgyy746fhmrt0nq955z6xmf80pkvrat0yq0hpknqtd00z8z68qqgkwet0vdskx6rfdenj6etkv4h8guc6gs5y5
 [nostr-epoxy]: https://github.com/Origami74/nostr-epoxy-reverse-proxy
+[marmot]: https://github.com/marmot-protocol/marmot
+
 
 ## Message types
 
@@ -387,6 +403,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `repo`            | Reference to the origin repository   | --                              | [C0](C0.md)                                        |
 | `runtime`         | Runtime or environment specification | --                              | [C0](C0.md)                                        |
 | `server`          | file storage server url              | --                              | [96](96.md)                                        |
+| `sound`           | shortcode, sound url, image url      | --                              | [51](51.md)                                        |
 | `subject`         | subject                              | --                              | [14](14.md), [17](17.md), [34](34.md)              |
 | `summary`         | summary                              | --                              | [23](23.md), [52](52.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels            | [58](58.md)                                        |