Update 71.md

56.md

@@ -22,7 +22,7 @@ are reporting.
 
 If reporting a note, an `e` tag MUST also be included referencing the note id.
 
-A `report type` string MUST be included as the 3rd entry to the `e` or `p` tag
+A `report type` string MUST be included as the 3rd entry to the `e`, `p` or `x` tag
 being reported, which consists of the following report types:
 
 - `nudity` - depictions of nudity, porn, etc.
@@ -33,7 +33,9 @@ being reported, which consists of the following report types:
 - `impersonation` - someone pretending to be someone else
 - `other` - for reports that don't fit in the above categories
 
-Some report tags only make sense for profile reports, such as `impersonation`
+Some report tags only make sense for profile reports, such as `impersonation`.
+
+- `x` tags SHOULD be info hash of a blob which is intended to be report. when the `x` tag is represented client MUST include an `e` tag which is the id of the event that contains the mentioned blob. also, additionally these events can contain a `server` tag to point to media servers which may contain the mentioned media.
 
 `l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) to support
 further qualification and querying.
@@ -45,7 +47,7 @@ Example events
 {
   "kind": 1984,
   "tags": [
-    ["p", <pubkey>, "nudity"],
+    ["p", "<pubkey>", "nudity"],
     ["L", "social.nos.ontology"],
     ["l", "NS-nud", "social.nos.ontology"]
   ],
@@ -58,8 +60,8 @@ Example events
 {
   "kind": 1984,
   "tags": [
-    ["e", <eventId>, "illegal"],
-    ["p", <pubkey>]
+    ["e", "<eventId>", "illegal"],
+    ["p", "<pubkey>"]
   ],
   "content": "He's insulting the king!",
   // other fields...
@@ -70,13 +72,26 @@ Example events
 {
   "kind": 1984,
   "tags": [
-    ["p", <impersonator pubkey>, "impersonation"]
+    ["p", "<impersonator pubkey>", "impersonation"]
   ],
   "content": "Profile is impersonating nostr:<victim bech32 pubkey>",
   // other fields...
 }
 ```
 
+```jsonc
+{
+  "kind": 1984,
+  "tags": [
+    ["x", "<blob hash>", "malware"],
+    ["e", "<event id which contains the blob on x tag>", "malware"],
+    ["server", "https://you-may-find-the-blob-here.com/path-to-url.ext"]
+  ],
+  "content": "This file contains malware software in it.",
+  // other fields...
+}
+```
+
 Client behavior
 ---------------
 

60.md

@@ -39,7 +39,7 @@ This NIP doesn't deal with users' *receiving* money from someone else, it's just
 }
 ```
 
-The wallet event is a parameterized replaceable event `kind:37375`.
+The wallet event is an addressable event `kind:37375`.
 
 Tags:
 * `d` - wallet ID.
@@ -57,7 +57,7 @@ Any tag, other than the `d` tag, can be [[NIP-44]] encrypted into the `.content`
 Due to addressable event being hard to delete, if a user wants to delete a wallet, they should empty the event and keep just the `d` identifier and add a `deleted` tag.
 
 ## Token Event
-Token events are used to record the unspent proofs that come from the mint.
+Token events are used to record unspent proofs.
 
 There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
 
@@ -73,7 +73,9 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
                 "secret": "z+zyxAVLRqN9lEjxuNPSyRJzEstbl69Jc1vtimvtkPg=",
                 "C": "0241d98a8197ef238a192d47edf191a9de78b657308937b4f7dd0aa53beae72c46"
             }
-        ]
+        ],
+        // tokens that were destroyed in the creation of this token
+        "del": [ "token-id-1" ]
     }),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ]
@@ -81,8 +83,11 @@ There can be multiple `kind:7375` events for the same mint, and multiple proofs
 }
 ```
 
-`.content` is a [[NIP-44]] encrypted payload storing the mint and the unencoded proofs.
-* `a` an optional tag linking the token to a specific wallet.
+ * `a` an optional tag linking the token to a specific wallet.
+ * `.content` is a [[NIP-44]] encrypted payload:
+   * `mint`: The mint the proofs belong to.
+   * `proofs`: unecoded proofs
+   * `del`: token-ids that were destroyed by the creation of this token. This assists with state transitions.
 
 ### Spending proofs
 When one or more proofs of a token are spent, the token event should be [[NIP-09]]-deleted and, if some proofs are unspent from the same token event, a new token event should be created rolling over the unspent proofs and adding any change outputs to the new token event.
@@ -96,7 +101,7 @@ Clients SHOULD publish `kind:7376` events to create a transaction history when t
     "content": nip44_encrypt([
         [ "direction", "in" ], // in = received, out = sent
         [ "amount", "1", "sat" ],
-        [ "e", "<event-id-of-spent-token>", "<relay-hint>", "created" ],
+        [ "e", "<event-id-of-created-token>", "<relay-hint>", "created" ],
     ]),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ],
@@ -160,7 +165,8 @@ Her client:
             { "id": "1", "amount": 1 },
             { "id": "2", "amount": 2 },
             { "id": "4", "amount": 8 },
-        ]
+        ],
+        "del": [ "event-id-1" ]
     }),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ]
@@ -168,6 +174,7 @@ Her client:
 }
 ```
 * MUST delete event `event-id-1`
+* SHOULD add the `event-id-1` to the `del` array of deleted token-ids.
 * SHOULD create a `kind:7376` event to record the spend
 ```jsonconc
 {

71.md

@@ -24,6 +24,11 @@ The primary source of video information is the `imeta` tags which is defined in
 
 Each `imeta` tag can be used to specify a variant of the video by the `dim` & `m` properties.
 
+This NIP defines the following additional `imeta` properties aside form those listen in [NIP-92](92.md) & [NIP-94](94.md):
+
+* `duration` (recommended) the duration of the video/audio in seconds (floating point number)
+* `bitrate` (recommended) the average bitrate of the video/audio in bits/sec
+
 Example:
 ```json
 [
@@ -37,6 +42,8 @@ Example:
     "fallback https://myotherserver.com/1080/12345.mp4",
     "fallback https://andanotherserver.com/1080/12345.mp4",
     "service nip96",
+    "bitrate 3000000",
+    "duration 29.223"
   ],
   ["imeta", 
     "dim 1280x720",
@@ -48,6 +55,8 @@ Example:
     "fallback https://myotherserver.com/720/12345.mp4",
     "fallback https://andanotherserver.com/720/12345.mp4",
     "service nip96",
+    "bitrate 2000000",
+    "duration 29.24"
   ],
   ["imeta", 
     "dim 1280x720",
@@ -59,6 +68,7 @@ Example:
     "fallback https://myotherserver.com/720/12345.m3u8",
     "fallback https://andanotherserver.com/720/12345.m3u8",
     "service nip96",
+    "duration 29.21"
   ],
 ]
 ```
@@ -72,7 +82,6 @@ Additionally `service nip96` may be included to allow clients to search the auth
 ### 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
-* `duration` (optional) video duration in seconds
 * `text-track` (optional, repeated) link to WebVTT file for video, type of supplementary information (captions/subtitles/chapters/metadata), optional language code
 * `content-warning` (optional) warning about content of NSFW video
 * `alt` (optional) description for accessibility
@@ -108,7 +117,6 @@ Additionally `service nip96` may be included to allow clients to search the auth
       "service nip96",
     ],
 
-    ["duration", <duration of video in seconds>],
     ["text-track", "<encoded `kind 6000` event>", "<recommended relay urls>"],
     ["content-warning", "<reason>"],
     ["segment", <start>, <end>, "<title>", "<thumbnail URL>"],
@@ -126,4 +134,4 @@ Additionally `service nip96` may be included to allow clients to search the auth
     ["r", "<url>"]
   ]
 }
-```
+```

92.md

@@ -6,10 +6,10 @@ Media Attachments
 
 Media attachments (images, videos, and other files) may be added to events by including a URL in the event content, along with a matching `imeta` tag.
 
-`imeta` ("inline metadata") tags add information about media URLs in the event's content. Each `imeta` tag SHOULD match a URL in the event content. Clients may replace imeta URLs with rich previews.
+`imeta` ("inline metadata") tags MAY add information about media URLs in the event's content. Each `imeta` tag SHOULD match a URL in the event content. Clients MAY replace imeta URLs with rich previews.
 
 The `imeta` tag is variadic, and each entry is a space-delimited key/value pair.
-Each `imeta` tag MUST have a `url`, and at least one other field. `imeta` may include
+Each `imeta` tag MUST have a `url`, and at least one other field. `imeta` MAY include
 any field specified by [NIP 94](./94.md). There SHOULD be only one `imeta` tag per URL.
 
 ## Example