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.

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

@@ -70,9 +70,9 @@ The `refs` tag can be optionally extended to enable clients to identify how many
 
 Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
 
-Patches in a patch set SHOULD include a NIP-10 `e` `reply` tag pointing to the previous patch.
+Patches in a patch set SHOULD include a [NIP-10](10.md) `e` `reply` tag pointing to the previous patch.
 
-The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` to the original root patch.
+The first patch revision in a patch revision SHOULD include a [NIP-10](10.md) `e` `reply` to the original root patch.
 
 ```jsonc
 {
@@ -125,7 +125,7 @@ Issues may have a `subject` tag, which clients can utilize to display a header.
 
 ## Replies
 
-Replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event should follow [NIP-22 comment](22.md).
+Replies to either a `kind:1621` (_issue_) or a `kind:1617` (_patch_) event should follow [NIP-22 comment](22.md).
 
 ## Status
 
@@ -161,9 +161,9 @@ Root Patches and Issues have a Status that defaults to 'Open' and can be set by
 }
 ```
 
-The Status event with the largest created_at date is valid.
+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 defaults to either that of the root-patch, or `1632` (Closed) if the root-patch's Status is `1631` and the patch-revision isn't tagged in the `1631` 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

53.md

@@ -129,3 +129,146 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
   "sig": "997f62ddfc0827c121043074d50cfce7a528e978c575722748629a4137c45b75bdbc84170bedc723ef0a5a4c3daebf1fef2e93f5e2ddb98e5d685d022c30b622"
 }
 ```
+
+## Interactive Rooms and Meetings
+-----
+
+`draft` `optional`
+
+Service providers want to offer Interactive Rooms to the Nostr network in such a way that participants can easily log and query by clients. This NIP describes a general framework to advertise rooms and their associated events.
+
+## Concepts
+
+### Interactive Room (kind:30312)
+
+A special event with `kind:30312` "Interactive Room" defines the configuration and properties of a virtual interactive space. Each room has a unique identifier and can host multiple events/meetings.
+
+```jsonc
+{
+  "kind": 30312,
+  "tags": [
+    ["d", "<unique identifier>"],              // Required: Room identifier
+    ["room", "<name of the room>"],            // Required: Display name
+    ["summary", "<description>"],              // Optional: Room description
+    ["image", "<preview image url>"],          // Optional: Room image
+    ["status", "<open, private, closed>"],     // Required: Room accessibility
+    ["service", "<url>"],                      // Required: URL to access the room
+    ["endpoint", "<url>"],                     // Optional: API endpoint for status/info
+    ["t", "<hashtag>"],                        // Optional: Multiple hashtags allowed
+    ["p", "<pubkey>", "<url>", "<role>", "<proof>"],  // Required: At least one provider
+    ["relays", "<url>", "<url>", /*...*/]     // Optional: Preferred relays
+  ],
+  "content": ""  // Usually empty, may contain additional metadata
+}
+```
+
+Room properties:
+* MUST be either open, private or closed. Closed means the room is not in operation.
+* MAY specify access control policy for private rooms (e.g. invite-only, payment required)
+* MAY persist when not in use
+* MUST have at least one provider with "Host" role
+* MAY have multiple providers with different roles
+Provider roles (p tags):
+* Host: Full room management capabilities
+* Moderator: Room moderation capabilities
+* Speaker: Allowed to present/speak
+* Optional proof field for role verification
+
+### Room Meeting (kind:30313)
+
+A special event with kind:30313 represents a scheduled or ongoing meeting within a room. It MUST reference its parent room using the d tag.
+
+```jsonc
+{
+  "kind": 30313,
+  "tags": [
+    ["d", "<event-unique-identifier>"],        // Required: Event identifier
+    ["a", "30312:<pubkey>:<room-id>", "wss://nostr.example.com"], // Required: Reference to parent room, 'd' from 30312
+    ["title", "<meeting-title>"],              // Required: Meeting title
+    ["summary", "<description>"],              // Optional: Meeting description
+    ["image", "<preview image url>"],          // Optional: Meeting image
+    ["starts", "<unix timestamp>"],            // Required: Start time
+    ["ends", "<unix timestamp>"],              // Optional: End time
+    ["status", "<planned, live, ended>"],      // Required: Meeting status
+    ["total_participants", "<number>"],        // Optional: Total registered
+    ["current_participants", "<number>"],      // Optional: Currently active
+    ["p", "<pubkey>", "<url>", "<role>"],     // Optional: Participant with role
+  ],
+  "content": ""  // Usually empty, may contain additional metadata
+}
+```
+
+Event properties:
+* MUST reference parent room via d tag
+* MUST have a status (planned/live/ended)
+* MUST have a start time
+* MAY track participant counts
+* MAY include participant roles specific to the event
+Event management:
+* Clients SHOULD update event status regularly when live
+* Events without updates for 1 hour MAY be considered ended
+* starts and ends timestamps SHOULD be updated when status changes
+
+Examples
+
+Interactive Room (kind:30312)
+
+```jsonc
+{
+  "kind": 30312,
+  "tags": [
+    ["d", "main-conference-room"],
+    ["room", "Main Conference Hall"],
+    ["summary", "Our primary conference space"],
+    ["image", "https://example.com/room.jpg"],
+    ["status", "open"],
+    ["service", "https://meet.example.com/room"],
+    ["endpoint", "https://api.example.com/room"],
+    ["t", "conference"],
+    ["p", "f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca", "wss://nostr.example.com/", "Owner"],
+    ["p", "14aeb..8dad4", "wss://provider2.com/", "Moderator"],
+    ["relays", "wss://relay1.com", "wss://relay2.com"]
+  ],
+  "content": ""
+}
+```
+
+Conference Event (kind:30313)
+
+```jsonc
+{
+  "kind": 30313,
+  "tags": [
+    ["d", "annual-meeting-2025"],
+    ["a", "30312:f7234bd4c1394dda46d09f35bd384dd30cc552ad5541990f98844fb06676e9ca:main-conference-room", "wss://nostr.example.com"]
+    ["title", "Annual Company Meeting 2025"],
+    ["summary", "Yearly company-wide meeting"],
+    ["image", "https://example.com/meeting.jpg"],
+    ["starts", "1676262123"],
+    ["ends", "1676269323"],
+    ["status", "live"],
+    ["total_participants", "180"],
+    ["current_participants", "175"],
+    ["p", "91cf9..4e5ca", "wss://provider1.com/", "Speaker"],
+  ],
+  "content": ""
+}
+```
+## Room Presence
+
+New `kind: 10312` provides an event which signals presence of a listener. 
+
+The presence event SHOULD be updated at regular intervals and clients SHOULD filter presence events older than 
+a given time window.
+
+**This kind `10312` is a regular replaceable event, as such presence can only be indicated in one room at a time.**
+
+```json
+{
+  "kind": 10312,
+  "tags": [
+    ["a" , "<room-a-tag>", "<relay-hint>", "root"],
+    ["hand", "1"] // hand raised flag
+  ]
+}
+```

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
+```

README.md

@@ -249,6 +249,8 @@ 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            |                                        |                        |
+| `34235`       | Addressable Video Event         | [71](71.md)                            |
+| `34236`       | Addressable Short Video Event   | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |
 | `38383`       | Peer-to-peer Order events       | [69](69.md)                            |
 | `39000-9`     | Group metadata events           | [29](29.md)                            |

xx.md

@@ -1,72 +0,0 @@
-NIP-XX
-======
-
-LLM Stuff
----------
-
-`draft` `optional`
-
-This NIP defines kinds related to LLM stuff.
-
-# Prompt diffs
- a way to publish LLM prompts that describe modifications to software projects. Where code diffs usually expire in a couple of releases and require constant upkeep,tThese "prompt diffs" enable way longer-lasting, shareable software modifications.
-
-## Abstract
-
-A prompt diff is a Nostr event that contains instructions for an LLM to modify a codebase. Prompt diffs describe the intent and let LLMs handle the implementation details.
-
-## Event Structure
-
-```json
-{
-   "kind": 496,
-   "content": "<human-readable-description>",
-   "tags": [
-       ["title", "<modification-title>"],
-       ["description", "<prompt>"],
-       ["r", "<git-repository-url>"],
-       ["t", "<tag>"],
-       ["model", "<suggested-llm-model>"],
-   ]
-}
-Required Tags
-
-title - Short title describing the modification
-r - Git repository URL this applies to
-prompt - The actual prompt containing modification instructions
-
-## Optional Tags
-
-t - Hashtags for categorization (#security, #performance, #feature-removal, etc.)
-model - Suggested LLM model that successfully applies this modification
-
-Example: Remove Edit Functionality from Amethyst
-json{
-    "kind": 496,
-    "pubkey": "...",
-    "created_at": 1234567890,
-    "content": "Removes the ability to edit kind:1 text notes in Amethyst",
-    "tags": [
-        ["title", "Remove Kind:1 Edit Functionality"],
-        ["description", "Remove all edit functionality for kind:1 events from the Amethyst Android app. This includes:\n\n1. Find and remove the edit button/icon from the note options menu (three dots menu) for kind:1 events\n2. Remove any edit action handlers, click listeners, or menu item cases related to editing kind:1 notes\n3. Remove or disable any UI components like EditPostView or EditPostDialog that are used for editing existing posts\n4. Keep the edit functionality for other event kinds if they exist (like kind:30023 long-form content)\n5. Remove any edit-related permissions checks or business logic specific to kind:1 events\n6. Clean up any unused imports or resources that were only used for kind:1 editing\n7. Do not remove the ability to create new kind:1 posts, only the ability to edit existing ones\n8. Look for edit functionality in:\n   - Note composition screens\n   - Note option menus  \n   - ViewModels handling note actions\n   - Any files with names containing 'Edit' and 'Note' or 'Post'\n\nMake sure the app still compiles and runs after these changes. The diff should be clean with no leftover dead code."],
-        ["r", "https://github.com/vitorpamplona/amethyst"],
-        ["t", "noedits"],
-        ["t", "amethyst"],
-        ["model", "claude-3.5-sonnet"],
-    ],
-    "sig": "..."
-}
-
-# Implementation Guidelines
-### For Prompt Authors
-
-Write clear, specific prompts that describe intent rather than implementation
-Include context about why changes should be made in certain locations
-Specify what should NOT be changed to prevent over-modification
-Add test commands to verify the modification works
-Test prompts against the current main branch of the repository
-
-# Security Considerations
-
-* Always review LLM-generated changes before applying
-* Prompt Injection Protection: Clients MUST sanitize repository file contents before passing to LLMs to prevent malicious code comments or documentation from hijacking the modification intent