Merge 22c700c944 into 2ace01cf1a

Co-authored-by: Jon Staab <shtaab@gmail.com>

101.md

@@ -0,0 +1,267 @@
+# NIP-101 - Forms On Nostr
+
+`draft` `optional` `author:abhay-raizada`
+
+The nip provides a way to implement a feedback mechanism(forms) on nostr.
+
+## Form Template - Public
+
+Event `30168` describes a form as a parametrized replaceable event, with `field` tags that contain the description of each form field, with optional settings
+
+```js
+{
+    "kind": 30168,
+    "content" : ""
+    "tags": [
+      ["d", "<form identifier>"],
+      ["name", "Name of the form"],
+      ["settings", JSON.stringify({description: "<description of the form."})],
+      ["field", "<fieldId>","<input-type>","<label for the field>","<Options (for option type)>", "<stringified JSON settings>"],
+      ["field", "<fieldId>", "option", "label for options field",
+        JSON.stringify([["<optionId1>", "option label", "<optionId2>", "option label"]]),
+        "<stringified JSON settings>"
+      ]
+    ],
+    "pubkey": "<Author of the form>"
+}
+```
+
+The different tags used to detail the form are described as:
+
+**d** - The unique identifier of a form, for a user
+
+**name** - The name of the form`
+
+**settings** - A form wide settings object, that can detail styles and visual representation of the form, certain fields in the object may be client specific
+
+**field** - contains the description of a form field.
+
+## Field Tag
+
+A field tag is described as the following array:
+`["field", FieldId, InputType, Label, Options, Field Settings ]`
+
+**FieldId** - Is used to identify the field in the form, can be any alphanumeric string.
+
+**InputType** - Can be one of: "text", "option", "label". All other types can be derived from the text type.
+
+**Label** - Value that describes the field, can be a question the user needs feedback eg: "What is your age?"
+
+**Options** - A stringified array of Options in case the user selected an option type.
+
+**Field Settings** - A stringified JSON that may contain metadata about a field, like wether the field is a "required" field or "prerequisites" for a field.
+
+## Options
+
+The options array is a stringified Array of Option Tags, where each option tag is
+represented as:
+`[<OptionId>, <label>, <optional config>]`
+
+**OptionId** - Similar to FieldId it is an alphanumeric Id that serves as an identifier for that Id in the form.
+
+**label** - A label describing the option.
+
+**Optional Config** - metadata object holds information about the options like "prerequisites".
+
+## Responses
+
+Response events are events that are attached to a form(3068 kind event), and the response data is stored in a `kind: 1069` event
+
+Response structure:
+
+```json
+{
+  "kind": 1069,
+  "content": "",
+  "tags": [
+    ["a", "30168:<pubkey of the author>:<form identifier>"],
+    [
+      "response",
+      "<FieldId>",
+      "<response as string>",
+      "<stringified metadata object>"
+    ]
+  ],
+  "pubkey": "Author of Response"
+}
+```
+
+The Response tag contains a "response" tag identifier "fieldId" the Id of the field as mentioned in the `kind:30168` event, response for the field as a string value, and a stringified metadata object.
+
+for option fields, the response is the id of the option selected. In case of multiple-choice fields these id's maybe delimited by a semi-colon, ";", For example:
+
+```json
+{
+  "kind": 1069,
+  "content": "",
+  "tags": [
+    ["a", "30168:<pubkey of the form author>:<formId>"],
+    [
+      "response",
+      "<FieldId>",
+      "ZCZC;XCZXCZ;Z34Z",
+      "<stringified metadata object>"
+    ]
+  ],
+  "pubkey": "Response author"
+}
+```
+
+## Response Editability
+
+if the form setting allows for editable responses. The latest timestamp event should be used to render the response.
+
+For uneditable responses, an open timestamp attestion [[03.md]] should be added, the event with an attestation for the earliest time should be used.
+
+## Access Control
+
+Access control is managed by sending a set of 3 keys to users using gift wrap events as described in [nip-59](./59.md) but with a few modifications.
+
+### Rumor
+
+A kind:18 rumor is created that holds the keys in a "key" tag. An example event is:
+
+```json
+{
+  "created_at": 1718188232,
+  "content": "",
+  "tags": [
+    [
+      "key",
+      "026b71adbdc2fd168c17778311950c40afd33a7e08b4d3159f441cfe37a83882",
+      "ca2f78e4fb0132232fbb673e4517498d2aa95d0cd2f9913d820a3fb91912c2d5",
+      "ce6b464f2aff3ca2aa46359a0b91d28027a0283e2946d9a7dc742d20470cdd52"
+    ]
+  ],
+  "kind": 18,
+  "pubkey": "373a87e2c80114a4c15c422a5c3a59acf36ff383cb534d576aea6b08f8e58ee0",
+  "id": "3e2f775af6867b2220bce59a5c2eacde3e2f405c7fc956af09939f7b02a60771"
+}
+```
+
+### Seal
+
+Works exactly as defined in [[59.md]]
+
+### Wrap
+
+The kind `1059` event also works similar to as described in [[59.md]] except that instead of referencing a users pubkey, we refer to an alias pubkey which is derived by hashing the form event information to the users pubkey as follows:
+
+1. The hash function used is SHA256.
+2. The input to the hash function is: `${30168}:${formAuthor}:${formId}:${userPub}`
+
+**formAuthor** - The pubkey for the `kind:30168` event
+**formId** - d-tag of the event
+**userPub** - pubkey to recepient being given the access.
+
+code for alias generation
+```ts
+import {bytesToHex } from "@noble/hashes/utils"
+import { sha256 } from "@noble/hashes/sha256"
+
+let aliasPubKey = bytesToHex(sha256(`${30168}:${formAuthor}:${formId}:${userPub}`));
+```
+
+### Keys
+
+The "key" tag in the `kind:18` rumor is represented as:
+`["key", "<view key>", "<signing key>", "voter key"]`
+
+- **View Key** - A key which used to encrypt a form content, the view key can make the form viewable.
+
+- **Signing Key** - The private key to the form event. Anybody with this key WILL BE ABLE TO EDIT THE FORM EVENT.
+
+- **Voter Key** - A key used to submit a response to the form in a poll-like scenario.
+
+### Submit Access.
+
+p-tags of the selected participants must be added to the form tags, and only query the responses from the p-tags mentioned in the form.
+
+### Encrypted Responses.
+
+Response tags are added to the `.content` field of the event and encrypted as per the spec in [nip-44](./44.md) by the responders private key and the form authors public key.
+
+### Private Forms only viewable by a group.
+
+Form fields and settings should be ommitted from the tags array and placed in the `.content` key, nip-44 encrypted by the corresponding public key of the view-key, and the signing key as private key. The selected responders can decrypt the form using the view key. The `tags` array is used to keep track of the allowed-responders identities.
+
+```js
+let encryptionKey = nip44.v2.utils.getConversationKey(
+  bytesToHex(signingKey),
+  getPublicKey(viewKey)
+);
+content = nip44.v2.encrypt(JSON.stringify(form), encryptionKey);
+```
+
+They view key is shared as a gift wrap to the participants as described above.
+
+### Polls
+
+There are some important parts for a form(general feedback mechanism) to become a poll.
+
+1. Only elligeble candidates must be allowed to vote.
+2. Participants shouldn't be able to associate a response to another participant.
+3. Participants should be able to verify that their response is counted.
+
+All of these conditions can be met by establishing a "Voter Key". The Voter Key is a private key generated by someone with edit access to the form (Issuer).
+
+The Issuer must then add a "p" tag to the form event, followed by a pubkey corresponding to the voterId.
+
+The voter must sign their responses with the issued voter key.
+
+The p tag is used to query eligible votes.
+
+Example form with a voter id.
+
+```json
+{
+  "content": "",
+  "created_at": 1718186931,
+  "id": "0bb2e5d100271c11957cc0a753246acbc91f29a20c40cbd4c560731e324ed069",
+  "kind": 30168,
+  "pubkey": "f767d6a03639aa0f9c0fd671d496086a0fcd86d958ea31f0789c9b27daf66d70",
+  "sig": "d4b725fff0811e64b05616b3320a291ee698d2dbb0f5ef6a9706ed9944aef38f48449916e9598b7a190f54def5c6141e625712d118550ef10da1ef26442f5f72",
+  "tags": [
+    ["d", "bestBreakfast"],
+    ["name", "This is the title of your form! Tap to edit."],
+      ["field", "egtD6v", "option", "What is the best breakfast?", "[[\"2KJ6h4\",\"Omelette\"],[\"1m3a5q\",\"Pancakes\"]]", "{\"renderElement\":\"radioButton\"}"
+    ]
+    ["p", "fb740690af9329e25b0a3c1f6ce6a24c4ff98dcba56d3579381ee340ea0350d4"],
+    ["p", "6b557be286b13d7a85b3823c630050db043c9a28bf606aa49c65b3db0c3208b6"]
+  ]
+}
+```
+
+## Querying Form Template & Responses
+
+form template maybe filtered using the form author's pubkey and the d-tag as follows
+
+```js
+const filter = {
+  kinds: [30168],
+  authors: [formIdPubkey],
+  "#d": [formIdentifier],
+};
+```
+
+Responses can be queried using the a-tag, and an optional authors tag depending the visibility of the form, for example
+
+```js
+const filter: Filter = {
+  kinds: [30169],
+  "#a": [`30168:${pubKey}:${formId}`],
+};
+if (allowedPubkeys) filter.authors = allowedPubkeys;
+```
+
+## Requesting Acces
+
+<TBD>
+
+## Tradeoffs
+
+- Alias pubkey on gift wrap means that there is no notification mechanism for the user, unless the user is expecting access to an event.
+
+- Alias pubkey also means that it can be checked that a particular user received a gift wrap for a form event, but it cannot be directly determined who all received the gift wraps, it also makes it easier in disambiguating between event kinds.  
+
+- Voter Key might make it anoymous to other participants, but the issuer can still know who a particular user voted for. In this implementation, the issuer is to be "trusted", but there may be out of band ways of having a "trustless" issuer. For example distrubiting voter Id chits in a physical meetup.

11.md

@@ -20,11 +20,9 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
   "contact": <administrative alternate contact>,
   "supported_nips": <a list of NIP numbers supported by the relay>,
   "software": <string identifying relay software URL>,
-  "version": <string version identifier>
+  "version": <string version identifier>,
   "privacy_policy": <a link to a text file describing the relay's privacy policy>,
   "terms_of_service": <a link to a text file describing the relay's term of service>,
-
-
 }
 ```
 
@@ -162,7 +160,7 @@ a specific niche kind or content. Normal anti-spam heuristics, for example, do n
 
 - `created_at_upper_limit`: 'created_at' upper limit
 
-- `default_limit`: The maximum returned events if you send a filter with the limit set to 0.
+- `default_limit`: The maximum returned events if you send a filter without a `limit`.
 
 ### Event Retention
 

42.md

@@ -32,6 +32,8 @@ And, when sent by clients, the following form:
 ["AUTH", <signed-event-json>]
 ```
 
+Clients MAY provide signed events from multiple pubkeys in a sequence of `AUTH` messages. Relays MUST treat all pubkeys as authenticated accordingly.
+
 `AUTH` messages sent by clients MUST be answered with an `OK` message, like any `EVENT` message.
 
 ### Canonical authentication event
@@ -69,7 +71,9 @@ relay: ["AUTH", "<challenge>"]
 client: ["REQ", "sub_1", {"kinds": [4]}]
 relay: ["CLOSED", "sub_1", "auth-required: we can't serve DMs to unauthenticated users"]
 client: ["AUTH", {"id": "abcdef...", ...}]
+client: ["AUTH", {"id": "abcde2...", ...}]
 relay: ["OK", "abcdef...", true, ""]
+relay: ["OK", "abcde2...", true, ""]
 client: ["REQ", "sub_1", {"kinds": [4]}]
 relay: ["EVENT", "sub_1", {...}]
 relay: ["EVENT", "sub_1", {...}]

47.md

@@ -188,6 +188,7 @@ Request:
     "params": {
         "invoice": "lnbc50n1...", // bolt11 invoice
         "amount": 123, // invoice amount in msats, optional
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
     }
 }
 ```
@@ -217,7 +218,7 @@ Request:
     "params": {
         "invoices": [
           {"id":"4da52c32a1", "invoice": "lnbc1...", "amount": 123}, // bolt11 invoice and amount in msats, amount is optional
-          {"id":"3da52c32a1", "invoice": "lnbc50n1..."},
+          {"id":"3da52c32a1", "invoice": "lnbc50n1...", "metadata": {} }, // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
         ],
     }
 }
@@ -324,7 +325,8 @@ Request:
         "amount": 123, // value in msats
         "description": "string", // invoice's description, optional
         "description_hash": "string", // invoice's description hash, optional
-        "expiry": 213 // expiry in seconds from time invoice is created, optional
+        "expiry": 213, // expiry in seconds from time invoice is created, optional
+        "metadata": {} // generic metadata that can be used to add things like zap/boostagram details for a payer name/comment/etc, optional
     }
 }
 ```
@@ -335,7 +337,7 @@ Response:
     "result_type": "make_invoice",
     "result": {
         "type": "incoming", // "incoming" for invoices, "outgoing" for payments
-        "state": "pending",
+        "state": "pending", // optional
         "invoice": "string", // encoded invoice, optional
         "description": "string", // invoice's description, optional
         "description_hash": "string", // invoice's description hash, optional
@@ -369,7 +371,7 @@ Response:
     "result_type": "lookup_invoice",
     "result": {
         "type": "incoming", // "incoming" for invoices, "outgoing" for payments
-        "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments)
+        "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments), optional
         "invoice": "string", // encoded invoice, optional
         "description": "string", // invoice's description, optional
         "description_hash": "string", // invoice's description hash, optional
@@ -418,7 +420,7 @@ Response:
         "transactions": [
             {
                "type": "incoming", // "incoming" for invoices, "outgoing" for payments
-               "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments)
+               "state": "pending", // can be "pending", "settled", "expired" (for invoices) or "failed" (for payments), optional
                "invoice": "string", // encoded invoice, optional
                "description": "string", // invoice's description, optional
                "description_hash": "string", // invoice's description hash, optional
@@ -495,7 +497,7 @@ Notification:
     "notification_type": "payment_received",
     "notification": {
         "type": "incoming",
-        "state": "settled",
+        "state": "settled", // optional
         "invoice": "string", // encoded invoice
         "description": "string", // invoice's description, optional
         "description_hash": "string", // invoice's description hash, optional
@@ -521,7 +523,7 @@ Notification:
     "notification_type": "payment_sent",
     "notification": {
         "type": "outgoing",
-        "state": "settled",
+        "state": "settled", // optional
         "invoice": "string", // encoded invoice
         "description": "string", // invoice's description, optional
         "description_hash": "string", // invoice's description hash, optional
@@ -612,6 +614,38 @@ The **client** should check the `encryption` tag in the `info` event to determin
 ## Using a dedicated relay
 This NIP does not specify any requirements on the type of relays used. However, if the user is using a custodial service it might make sense to use a relay that is hosted by the custodial service. The relay may then enforce authentication to prevent metadata leaks. Not depending on a 3rd party relay would also improve reliability in this case.
 
+## Metadata
+Metadata MAY be stored by the **wallet service** alongside invoices and payments. The metadata MUST be no more than 4096 characters, otherwise MUST be dropped. This is to ensure transactions do not get too large to be relayed.
+
+NWC relays SHOULD allow at least a payload size of 64KB and **clients** SHOULD fetch small page sizes (maximum of 20 transactions per page) otherwise there is risk of `list_transactions` responses being rejected.
+
+Here are some properties that are recognized by some NWC clients:
+
+```jsonc
+{
+  "comment": "string", // LUD-12 comment
+  "payer_data": {
+    "email": "string",
+    "name": "string",
+    "pubkey": "string",
+  }, // LUD-18 payer data
+  "recipient_data": {
+    "identifier": "string"
+  }, // similar to LUD-18 payer data, but to record recipient data e.g. the lightning address of the recipient
+  "nostr": {
+    "pubkey": "string",
+    "tags": [],
+    // ... rest of zap request event
+  }, // NIP-57 Zap Request event (kind 9734)
+  "tlv_records": [
+    {
+      "type": 5482373484, // tlv type
+      "value": "0123456789abcdef" // hex encoded tlv value
+    }
+  ] // keysend TLV records (e.g. for podcasting 2.0 boostagrams)
+} & Record<string, unknown>;
+```
+
 ## Appendix
 
 ### Example NIP-47 info event
@@ -633,3 +667,21 @@ This NIP does not specify any requirements on the type of relays used. However,
   "sig": "31f57b369459b5306a5353aa9e03be7fbde169bc881c3233625605dd12f53548179def16b9fe1137e6465d7e4d5bb27ce81fd6e75908c46b06269f4233c845d8"
 }
 ```
+
+### Deep-links
+
+Wallet applications can register deeplinks in mobile systems to make it possible to create a linking UX that doesn't require the user scanning a QR code or pasting some code.
+
+`nostrnwc://connect` and `nostrnwc+{app_name}://connect` can be registered by wallet apps and queried by apps that want to receive an NWC pairing code.
+
+All URI parameters, MUST be URI-encoded.
+
+URI parameters:
+ * `appicon` -- URL to an icon of the client that wants to create a connection.
+ * `appname` -- Name of the client that wants to create a connection.
+ * `callback` -- URI schema the wallet should open with the connection string
+
+Once a connection has been created by the wallet, it should be returned to the client by opening the callback with the following parameters
+ * `value` -- NWC pairing code (e.g. `nostr+walletconnect://...`)
+
+

51.md

@@ -54,7 +54,7 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
 | 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)   |
 | Curation sets         | 30004 | groups of articles picked by users as interesting and/or belonging to the same category      | `"a"` (kind:30023 articles), `"e"` (kind:1 notes)                                   |
-| Curation sets         | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"a"` (kind:21 videos)                                                              |
+| Curation sets         | 30005 | groups of videos picked by users as interesting and/or belonging to the same category        | `"e"` (kind:21 videos)                                                              |
 | Kind mute sets        | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string                                   | `"p"` (pubkeys)                                                                     |
 | Interest sets         | 30015 | interest topics represented by a bunch of "hashtags"                                         | `"t"` (hashtags)                                                                    |
 | Emoji sets            | 30030 | categorized emoji groups                                                                     | `"emoji"` (see [NIP-30](30.md))                                                     |

53.md

@@ -6,13 +6,13 @@ Live Activities
 
 `draft` `optional`
 
-Service providers want to offer live activities 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 the involvement of pubkeys in such live activities.
+This NIP introduces event kinds to advertise live spaces and the participation of pubkeys in them.
 
-## Concepts
+## Live Streaming
 
-### Live Event
+A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participants of a live stream.
 
-A special event with `kind:30311` "Live Event" is defined as an _addressable event_ of public `p` tags. Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
+Each `p` tag SHOULD have a **displayable** marker name for the current role (e.g. `Host`, `Speaker`, `Participant`) of the user in the event and the relay information MAY be empty. This event will be constantly updated as participants join and leave the activity.
 
 For example:
 
@@ -63,13 +63,13 @@ This feature is important to avoid malicious event owners adding large account h
 
 ### Live Chat Message
 
-Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to. 
+Event `kind:1311` is live chat's channel message. Clients MUST include the `a` tag of the activity. An `e` tag denotes the direct parent message this post is replying to.
 
 ```jsonc
 {
   "kind": 1311,
   "tags": [
-    ["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>", "root"],
+    ["a", "30311:<Community event author pubkey>:<d-identifier of the community>", "<Optional relay url>"],
   ],
   "content": "Zaps to live streams is beautiful.",
   // other fields...
@@ -84,13 +84,9 @@ Event `kind:1311` is live chat's channel message. Clients MUST include the `a` t
 
 Hosts may choose to pin one or more live chat messages by updating the `pinned` tags in the live event kind `30311`.
 
-## Use Cases
+### Examples
 
-Common use cases include meeting rooms/workshops, watch-together activities, or event spaces, such as [zap.stream](https://zap.stream).
-
-## Example
-
-### Live Streaming
+#### Live Streaming
 
 ```json
 {
@@ -114,7 +110,7 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
 }
 ```
 
-### Live Streaming chat message
+#### Live Streaming chat message
 
 ```json
 {
@@ -130,18 +126,13 @@ Common use cases include meeting rooms/workshops, watch-together activities, or
 }
 ```
 
-## Interactive Rooms and Meetings
------
+## Meeting Spaces
 
-`draft` `optional`
+Meeting spaces contain one or more video/audio rooms where users can join and participate in the streaming.
 
-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.
+### Meeting Space Event (kind:30312)
 
-## 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.
+A special event with `kind:30312` "Space Host" defines the configuration and properties of a virtual interactive space. Each space has a unique identifier and can host multiple events/meetings.
 
 ```jsonc
 {
@@ -162,19 +153,20 @@ A special event with `kind:30312` "Interactive Room" defines the configuration a
 }
 ```
 
-Room properties:
+Space 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)
+### Meeting Room Events (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.
 
@@ -183,7 +175,7 @@ A special event with kind:30313 represents a scheduled or ongoing meeting within
   "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
+    ["a", "30312:<pubkey>:<room-id>", "wss://nostr.example.com"], // Required: Reference to parent space, 'd' from 30312
     ["title", "<meeting-title>"],              // Required: Meeting title
     ["summary", "<description>"],              // Optional: Meeting description
     ["image", "<preview image url>"],          // Optional: Meeting image
@@ -204,14 +196,15 @@ Event properties:
 * 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
+### Examples
 
-Interactive Room (kind:30312)
+#### Meeting Space (kind:30312)
 
 ```jsonc
 {
@@ -233,7 +226,7 @@ Interactive Room (kind:30312)
 }
 ```
 
-Conference Event (kind:30313)
+#### Meeting room (kind:30313)
 
 ```jsonc
 {
@@ -254,11 +247,11 @@ Conference Event (kind:30313)
   "content": ""
 }
 ```
-## Room Presence
+### Room Presence
 
-New `kind: 10312` provides an event which signals presence of a listener. 
+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 
+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.**

57.md

@@ -12,7 +12,7 @@ Having lightning receipts on nostr allows clients to display lightning payments
 
 ## Protocol flow
 
-1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud06 or lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
+1. Client calculates a recipient's lnurl pay request url from the `zap` tag on the event being zapped (see Appendix G), or by decoding their lud16 field on their profile according to the [lnurl specifications](https://github.com/lnurl/luds). The client MUST send a GET request to this url and parse the response. If `allowsNostr` exists and it is `true`, and if `nostrPubkey` exists and is a valid BIP 340 public key in hex, the client should associate this information with the user, along with the response's `callback`, `minSendable`, and `maxSendable` values.
 2. Clients may choose to display a lightning zap button on each post or on a user's profile. If the user's lnurl pay request endpoint supports nostr, the client SHOULD use this NIP to request a `zap receipt` rather than a normal lnurl invoice.
 3. When a user (the "sender") indicates they want to send a zap to another user (the "recipient"), the client should create a `zap request` event as described in Appendix A of this NIP and sign it.
 4. Instead of publishing the `zap request`, the `9734` event should instead be sent to the `callback` url received from the lnurl pay endpoint for the recipient using a GET request. See Appendix B for details and an example.

66.md

@@ -28,10 +28,8 @@ Other tags include:
 - `N` - NIPs supported by the relay
 - `R` - Keys corresponding to requirements per [NIP 11](https://github.com/nostr-protocol/nips/blob/master/11.md)'s `limitations` array, including `auth`, `writes`, `pow`, and `payment`. False values should be specified using a `!` prefix, for example `!auth`.
 - `t` - A topic associated with this relay
-- `k` - An event kind accepted by the relay
-- `!k` - An event kind not accepted by the relay
+- `k` - Accepted and unaccepted kinds (false values prepended by `!`) 
 - `g` - A [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash
-- `l` - A language tag
 
 Tags with more than one value should be repeated, rather than putting all values in a single tag, for example `[["t", "cats"], ["t", "dogs"]]`, rather than `[["t", "cats", "dogs"]]`.
 

71.md

@@ -85,15 +85,15 @@ Additionally `service nip96` may be included to allow clients to search the auth
 
 ```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>,
+  "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": 21 | 22,
   "content": "<summary / description of video>",
   "tags": [
     ["title", "<title of video>"],
     ["published_at", "<unix timestamp>"],
-    ["alt", <description>],
+    ["alt", "<description>"],
 
     // video Data
     ["imeta",
@@ -108,7 +108,7 @@ Additionally `service nip96` may be included to allow clients to search the auth
       "service nip96",
     ],
 
-    ["duration", <duration of video in seconds>],
+    ["duration", "<duration of video in seconds>"],
     ["text-track", "<encoded `kind 6000` event>", "<recommended relay urls>"],
     ["content-warning", "<reason>"],
     ["segment", <start>, <end>, "<title>", "<thumbnail URL>"],

96.md

@@ -1,3 +1,5 @@
+> __Warning__  `unrecommended`: deprecated in favor of [NIP-B7](B7.md)
+
 NIP-96
 ======
 

99.md

@@ -40,7 +40,7 @@ The following tags, used for structured metadata, are standardized and SHOULD be
   - `"<number>"` is the amount in numeric format (but included in the tag as a string)
   - `"<currency>"` is the currency unit in 3-character ISO 4217 format or ISO 4217-like currency code (e.g. `"btc"`, `"eth"`).
   - `"<frequency>"` is optional and can be used to describe recurring payments. SHOULD be in noun format (hour, day, week, month, year, etc.)
-- - `"status"` (optional), the status of the listing. SHOULD be either "active" or "sold".
+- `"status"` (optional), the status of the listing. SHOULD be either "active" or "sold".
 
 #### `price` examples
 
@@ -48,7 +48,7 @@ The following tags, used for structured metadata, are standardized and SHOULD be
 - €15 per month `["price", "15", "EUR", "month"]`
 - £50,000 per year `["price", "50000", "GBP", "year"]`
 
-Other standard tags that might be useful.
+Other common tags that might be useful.
 
 - `"g"`, a geohash for more precise location
 

BREAKING.md

@@ -1,68 +0,0 @@
-# Breaking Changes
-
-This is a history of NIP changes that potentially break pre-existing implementations, in
-reverse chronological order.
-
-| Date        | Commit    | NIP      | Change |
-| ----------- | --------- | -------- | ------ |
-| 2025-02-14  | [81908b6e](https://github.com/nostr-protocol/nips/commit/81908b6e) | [07](07.md), [46](46.md), [55](55.md) | `getRelays` and `get_relays` were removed |
-| 2025-02-07  | [0023ca81](https://github.com/nostr-protocol/nips/commit/0023ca81) | [10](10.md) | `"mention"` marker was removed |
-| 2025-01-31  | [6a4b125a](https://github.com/nostr-protocol/nips/commit/6a4b125a) | [71](71.md) | video events were changed to regular |
-| 2024-12-05  | [6d16019e](https://github.com/nostr-protocol/nips/commit/6d16019e) | [46](46.md) | message encryption was changed to NIP-44 |
-| 2024-11-12  | [2838e3bd](https://github.com/nostr-protocol/nips/commit/2838e3bd) | [29](29.md) | `kind: 12` and `kind: 10` were removed (use `kind: 1111` instead) |
-| 2024-11-12  | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | NIP-05 login was removed |
-| 2024-11-12  | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `create_account` method was removed |
-| 2024-11-12  | [926a51e7](https://github.com/nostr-protocol/nips/commit/926a51e7) | [46](46.md) | `connect` params and result were changed |
-| 2024-10-29  | [f1e8d2c4](https://github.com/nostr-protocol/nips/commit/f1e8d2c4) | [46](46.md) | bunker URL should use `remote-signer-key` |
-| 2024-10-15  | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [71](71.md) | some tags were replaced with `imeta` tag |
-| 2024-10-15  | [1cda2dcc](https://github.com/nostr-protocol/nips/commit/1cda2dcc) | [71](71.md) | `kind: 34237` was dropped |
-| 2024-10-07  | [7bb8997b](https://github.com/nostr-protocol/nips/commit/7bb8997b) | [55](55.md) | some fields and passing data were changed |
-| 2024-08-18  | [3aff37bd](https://github.com/nostr-protocol/nips/commit/3aff37bd) | [54](54.md) | content should be Asciidoc |
-| 2024-07-31  | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
-| 2024-07-30  | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [45](45.md) | NIP-45 was deprecated |
-| 2024-07-26  | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [19](19.md) | `nrelay` was deprecated |
-| 2024-07-23  | [0227a2cd](https://github.com/nostr-protocol/nips/commit/0227a2cd) | [01](01.md) | events should be sorted by id after created_at |
-| 2024-06-06  | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted |
-| 2024-06-06  | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [55](55.md) | NIP number was changed |
-| 2024-05-25  | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [71](71.md) | `aes-256-gcm` tag was removed |
-| 2024-05-07  | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) | [25](25.md) | e-tags were changed to not include entire thread |
-| 2024-04-30  | [bad88262](https://github.com/nostr-protocol/nips/commit/bad88262) | [34](34.md) | `earliest-unique-commit` tag was removed (use `r` tag instead) |
-| 2024-02-25  | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [18](18.md) | quote repost should use `q` tag |
-| 2024-02-21  | [c6cd655c](https://github.com/nostr-protocol/nips/commit/c6cd655c) | [46](46.md) | Params were stringified |
-| 2024-02-16  | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [49](49.md) | Password first normalized to NFKC |
-| 2024-02-15  | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [39](39.md) | PGP identity was removed |
-| 2024-02-07  | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [46](46.md) | Connection token format was changed |
-| 2024-01-30  | [1a2b21b6](https://github.com/nostr-protocol/nips/commit/1a2b21b6) | [59](59.md) | `p` tag became optional |
-| 2023-01-27  | [c2f34817](https://github.com/nostr-protocol/nips/commit/c2f34817) | [47](47.md) | optional expiration tag should be honored |
-| 2024-01-10  | [3d8652ea](https://github.com/nostr-protocol/nips/commit/3d8652ea) | [02](02.md), [51](51.md) | list entries should be chronological |
-| 2023-12-30  | [29869821](https://github.com/nostr-protocol/nips/commit/29869821) | [52](52.md) | `name` tag was removed (use `title` tag instead) |
-| 2023-12-27  | [17c67ef5](https://github.com/nostr-protocol/nips/commit/17c67ef5) | [94](94.md) | `aes-256-gcm` tag was removed |
-| 2023-12-03  | [0ba45895](https://github.com/nostr-protocol/nips/commit/0ba45895) | [01](01.md) | WebSocket status code `4000` was replaced by `CLOSED` message |
-| 2023-11-28  | [6de35f9e](https://github.com/nostr-protocol/nips/commit/6de35f9e) | [89](89.md) | `client` tag value was changed |
-| 2023-11-20  | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [51](51.md) | `kind: 30001` was deprecated |
-| 2023-11-20  | [7822a8b1](https://github.com/nostr-protocol/nips/commit/7822a8b1) | [51](51.md) | the meaning of `kind: 30000` was changed |
-| 2023-11-11  | [cbdca1e9](https://github.com/nostr-protocol/nips/commit/cbdca1e9) | [84](84.md) | `range` tag was removed |
-| 2023-11-10  | [c945d8bd](https://github.com/nostr-protocol/nips/commit/c945d8bd) | [32](32.md) | `l` tag annotations was removed |
-| 2023-11-07  | [108b7f16](https://github.com/nostr-protocol/nips/commit/108b7f16) | [01](01.md) | `OK` message must have 4 items |
-| 2023-10-17  | [cf672b76](https://github.com/nostr-protocol/nips/commit/cf672b76) | [03](03.md) | `block` tag was removed |
-| 2023-09-29  | [7dc6385f](https://github.com/nostr-protocol/nips/commit/7dc6385f) | [57](57.md) | optional `a` tag was included in `zap receipt` |
-| 2023-08-21  | [89915e02](https://github.com/nostr-protocol/nips/commit/89915e02) | [11](11.md) | `min_prefix` was removed |
-| 2023-08-20  | [37c4375e](https://github.com/nostr-protocol/nips/commit/37c4375e) | [01](01.md) | replaceable events with same timestamp should be retained event with lowest id |
-| 2023-08-15  | [88ee873c](https://github.com/nostr-protocol/nips/commit/88ee873c) | [15](15.md) | `countries` tag was renamed to `regions` |
-| 2023-08-14  | [72bb8a12](https://github.com/nostr-protocol/nips/commit/72bb8a12) | [12](12.md), [16](16.md), [20](20.md), [33](33.md) | NIP-12, 16, 20 and 33 were merged into NIP-01 |
-| 2023-08-11  | [d87f8617](https://github.com/nostr-protocol/nips/commit/d87f8617) | [25](25.md) | empty `content` should be considered as "+" |
-| 2023-08-01  | [5d63b157](https://github.com/nostr-protocol/nips/commit/5d63b157) | [57](57.md) | `zap` tag was changed |
-| 2023-07-15  | [d1814405](https://github.com/nostr-protocol/nips/commit/d1814405) | [01](01.md) | `since` and `until` filters should be `since <= created_at <= until` |
-| 2023-07-12  | [a1cd2bd8](https://github.com/nostr-protocol/nips/commit/a1cd2bd8) | [25](25.md) | custom emoji was supported |
-| 2023-06-18  | [83cbd3e1](https://github.com/nostr-protocol/nips/commit/83cbd3e1) | [11](11.md) | `image` was renamed to `icon` |
-| 2023-04-13  | [bf0a0da6](https://github.com/nostr-protocol/nips/commit/bf0a0da6) | [15](15.md) | different NIP was re-added as NIP-15 |
-| 2023-04-09  | [fb5b7c73](https://github.com/nostr-protocol/nips/commit/fb5b7c73) | [15](15.md) | NIP-15 was merged into NIP-01 |
-| 2023-03-29  | [599e1313](https://github.com/nostr-protocol/nips/commit/599e1313) | [18](18.md) | NIP-18 was bring back |
-| 2023-03-15  | [e1004d3d](https://github.com/nostr-protocol/nips/commit/e1004d3d) | [19](19.md) | `1: relay` was changed to optionally |
-
-Breaking changes prior to 2023-03-01 are not yet documented.
-
-## NOTES
-
-- If it isn't clear that a change is breaking or not, we list it.
-- The date is the date it was merged, not necessarily the date of the commit.

EE.md

@@ -82,7 +82,7 @@ This is a concise overview of the security trade-offs and considerations of this
 
 ### Forward Secrecy and Post-compromise Security
 
-- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (expecially the [exporter secret](#group-events)) for longer than absolutely necessary.
+- As per the MLS spec, keys are deleted as soon as they are used to encrypt or decrypt a message. This is usually handled by the MLS implementation library itself but attention needs to be paid by clients to ensure they're not storing secrets (especially the [exporter secret](#group-events)) for longer than absolutely necessary.
 - This NIP maintains MLS forward secrecy and post-compromise security guarantees. You can read more about those in the MLS Architectural Overview section on [Forward Secrecy and Post-compromise Security](https://www.ietf.org/archive/id/draft-ietf-mls-architecture-15.html#name-forward-and-post-compromise).
 
 ### Leakage of various keys

README.md

@@ -11,11 +11,10 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [Message Types](#message-types)
   - [Client to Relay](#client-to-relay)
   - [Relay to Client](#relay-to-client)
-- [Standardized Tags](#standardized-tags)
+- [Common Tags](#common-tags)
 - [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
 - [Is this repository a centralizing factor?](#is-this-repository-a-centralizing-factor)
 - [How this repository works](#how-this-repository-works)
-- [Breaking Changes](#breaking-changes)
 - [License](#license)
 
 ---
@@ -99,7 +98,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-90: Data Vending Machines](90.md)
 - [NIP-92: Media Attachments](92.md)
 - [NIP-94: File Metadata](94.md)
-- [NIP-96: HTTP File Storage Integration](96.md)
+- [NIP-96: HTTP File Storage Integration](96.md) --- **unrecommended**: replaced by blossom APIs
 - [NIP-98: HTTP Auth](98.md)
 - [NIP-99: Classified Listings](99.md)
 - [NIP-A0: Voice Messages](A0.md)
@@ -206,7 +205,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10050`       | Relay list to receive DMs       | [51](51.md), [17](17.md)               |
 | `10051`       | KeyPackage Relays List          | [EE](EE.md)                            |
 | `10063`       | User server list                | [Blossom][blossom]                     |
-| `10096`       | File storage server list        | [96](96.md)                            |
+| `10096`       | File storage server list        | [96](96.md) (deprecated)               |
 | `10166`       | Relay Monitor Announcement      | [66](66.md)                            |
 | `10312`       | Room Presence                   | [53](53.md)                            |
 | `10377`       | Proxy Announcement              | [Nostr Epoxy][nostr-epoxy]             |
@@ -312,7 +311,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `AUTH`   | used to send authentication challenges                  | [42](42.md) |
 | `COUNT`  | used to send requested event counts to clients          | [45](45.md) |
 
-## Standardized Tags
+## Common Tags
 
 | name              | value                                | other parameters                | NIP                                                |
 | ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- |
@@ -408,10 +407,6 @@ Standards may emerge in two ways: the first way is that someone starts doing som
 
 These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.
 
-## Breaking Changes
-
-[Breaking Changes](BREAKING.md)
-
 ## License
 
 All NIPs are public domain.