note about reusing nip53 interaction kinds

Co-authored-by: Pablo Fernandez <pfer@me.com>

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,8 +170,9 @@ 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`, 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`, `mute` and `error` for when none of that fits.

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 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.
 
 
 ## 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 |
-| Favorite relays   | 10012 | user favorite relays and pointers to relay sets             | `"relay"` (relay URLs) and `"a"` (kind:30002 relay set)                                             |
+| Relay feeds       | 10012 | user favorite browsable relays (and 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)                                    |

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

5E.md

@@ -0,0 +1,124 @@
+# NIP-5E
+
+## Nostr Live Streams
+
+`draft` `optional` `dep:53` `dep:92` `dep:94` `dep:40`
+
+Describes a way to distribute live video streams via nostr.
+
+**"Live Video" in this context implies segmented video streams like HLS or DASH**
+
+All other live interactions (chat/zap/raid etc) from [NIP-53](53.md) are re-used here so that the main stream event is interchangeable.
+
+## N94 Stream
+
+A new `kind: 1053` event lists a single live stream.
+
+Example:
+
+```jsonc
+{
+  "kind": 1053,
+  "tags": [
+    ["title", "<name of the event>"],
+    ["summary", "<description>"],
+    ["image", "<preview image url>"],
+    [
+      "variant",
+      "dim 1920x1080",
+      "bitrate 5000000",
+      "m video/mp2t",
+      "d 1080p"
+    ],
+    [
+      "variant",
+      "dim 1280x720",
+      "bitrate 3000000",
+      "m video/mp2t",
+      "d 720p"
+    ],
+    [
+      "variant",
+      "dim 1920x1080",
+      "bitrate 6000000",
+      "m video/mp4",
+      "d 1080p-fmp4"
+    ],
+    ["t", "hashtag"],
+    ["relays", "wss://one.com", "wss://two.com", /*...*/],
+    ["pinned", "<event id of pinned live chat message>"],
+    ["goal", "<event id of stream goal>"]
+  ],
+  "content": "",
+  // other fields...
+}
+```
+
+The `variant` tag works like `imeta` tag from [NIP-92](92.md) and defines a variant stream.
+
+The `d` entry of the `variant` tag is used in the NIP-94 segment event for variant following.
+
+## N94 Segment
+
+Each segment of the stream is a [NIP-94](94.md) event which describes where the file can be found and its hash.
+
+```jsonc
+{
+  "kind": 1063,
+  "tags": [
+    ["d", "1080p"],
+    ["k", "1053"],
+    ["e", "<id-of-kind-1053>"],
+    ["x", "<sha256>"],
+    ["m", "video/mp2t"],
+    ["dim", "1920x1080"],
+    ["duration", "2.033"],
+    ["index", "1234"],
+    ["url", "https://example.com/1234.ts"],
+    ["fallback", "https://another.com/1234.ts"],
+    ["expiration", "1752752349"],
+    ["service", "blossom"],
+    ...
+  ]
+  // other fields...
+}
+```
+
+Aside from the standard NIP-94 tags:
+
+- `d`: Variant stream tag.
+- `index`: Segment index, a simple counter. Used of ordering.
+
+`service` tag should be used for extended censorship resitance by looking up the appropriate server list (Blossom) of the uploader and checking for files on alternate servers.
+
+An [NIP-40](40.md) `expiration` tag MAY be used to automatically clean up segments after a specified time, which is useful for live streams that are not intended to persist. Producers SHOULD also automatically delete segment files from file servers.
+
+## Implementors
+
+### Consumers
+
+Clients wishing to implement a player should use [MSE](https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API) or similar technologies which allow appending data to the player buffer.
+
+Other services MAY provide a compatability layer with [NIP-53](53.md) live streams by producing HLS playlists over a N94 Stream.
+
+Clients SHOULD listen for new segments using a filter like this:
+
+`{"kinds":[1063],"#e":["<id-of-kind-1053>"],"limit":10}`
+
+Leaving the subscription open will allow clients to be notified immediately as segments are published and can fetch those segments and append them to the player buffer, enabling live playback without delays.
+
+### Producers
+
+Segment length SHOULD be carefully considered as a trade off between stream delay and total number of NIP-94 events / segment files.
+
+Using `expiration` tags on N94 segments and deleting segment files from servers SHOULD be used to cleanup streams which don't want to persist after the stream is finished.
+
+## Example implementations:
+
+### Player
+
+[zap.stream](https://github.com/v0l/zap.stream/blob/main/src/element/stream/n94-player.tsx)
+
+### Producer
+
+[n94](https://github.com/v0l/zap-stream-core/tree/main/crates/n94)

69.md

@@ -80,6 +80,7 @@ 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
 

72.md

@@ -41,19 +41,55 @@ The goal of this NIP is to enable public communities. It defines the replaceable
 
 # Posting to a community
 
-Any Nostr event can be posted to a community. Clients MUST add one or more community `a` tags, each with a recommended relay.
+[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.
 
 ```jsonc
 {
-  "kind": 1,
+  "kind": 1111,
   "tags": [
-    ["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
+    ["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"],
   ],
-  "content": "hello world",
+  "content": "Hi everyone. It's great to be here!",
   // 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.

87.md

@@ -0,0 +1,142 @@
+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 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 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 structure of these events is very similar to [NIP-23](23.md) long-form content events.
 

README.md

@@ -93,6 +93,7 @@ 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)
@@ -101,13 +102,14 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-96: HTTP File Storage Integration](96.md)
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
+- [NIP-5E: Nostr Live Streams](5E.md)
 - [NIP-B0: Web Bookmarks](B0.md)
 - [NIP-B7: Blossom](B7.md)
 - [NIP-C0: Code Snippets](C0.md)
+- [NIP-7D: Threads](7D.md)
 - [NIP-C7: Chats](C7.md)
 
 ## Event Kinds
-
 | kind          | description                     | NIP                                    |
 | ------------- | ------------------------------- | -------------------------------------- |
 | `0`           | User Metadata                   | [01](01.md)                            |
@@ -147,6 +149,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1021`        | Bid                             | [15](15.md)                            |
 | `1022`        | Bid confirmation                | [15](15.md)                            |
 | `1040`        | OpenTimestamps                  | [03](03.md)                            |
+| `1053`        | Live Stream                     | [5E](5E.md)                            |
 | `1059`        | Gift Wrap                       | [59](59.md)                            |
 | `1063`        | File Metadata                   | [94](94.md)                            |
 | `1068`        | Poll                            | [88](88.md)                            |
@@ -200,6 +203,7 @@ 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)                            |
@@ -247,9 +251,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            |                                        |
 | `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)                            |

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