wip

29.md

@@ -122,23 +122,29 @@ Each moderation action uses a different kind and requires different arguments, w
 
 | kind | name                | tags                                           |
 | ---  | ---                 | ---                                            |
-| 9000 | `put-user`          | `p` with pubkey hex and optional roles         |
-| 9001 | `remove-user`       | `p` with pubkey hex                            |
-| 9002 | `edit-metadata`     | fields from `kind:39000` to be modified        |
 | 9005 | `delete-event`      | `e` with event id hex                          |
-| 9007 | `create-group`      |                                                |
-| 9008 | `delete-group`      |                                                |
-| 9009 | `create-invite`     |                                                |
 
 It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
 
+### Metadata / Group creation
+
+Admins of a group can publish a `kind:39000` event to edit a group metadata. Relays may allow using this event to create a new group when an non-existing `d` tag is used. Relays should copy the payload of this event AS-IS and resign it with their key.
+
+The metadata event may include extra metadata about the group, for example, it may include `k` tags for the type of kinds this group is centered around.
+
+Relays SHOULD reject `kind:39000` events from non-admins and MUST not re-sign the event with their own key.
+
+### Membership events
+
+Admins of a group should publish `kind:39001` and `kind:39002` to modify the admin and members list respectively. Just like with `kind:39000`, relays should re-sign with their own key when they receive an event from an admin pubkey and MUST not re-sign the event when receiving the event from an unauthorized list.
+
 ### Group metadata events
 
 These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
 
 - *group metadata* (`kind:39000`) (optional)
 
-This event defines the metadata for the group -- basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn't accept these events if they're signed by anyone else.
+This event defines the metadata for the group -- basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn't accept these events if they're signed by anyone else other than admins.
 
 If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.
 

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`, `p` or `x` tag
+A `report type` string MUST be included as the 3rd entry to the `e` or `p` tag
 being reported, which consists of the following report types:
 
 - `nudity` - depictions of nudity, porn, etc.
@@ -33,9 +33,7 @@ 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`.
-
-- `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.
+Some report tags only make sense for profile reports, such as `impersonation`
 
 `l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) to support
 further qualification and querying.
@@ -47,7 +45,7 @@ Example events
 {
   "kind": 1984,
   "tags": [
-    ["p", "<pubkey>", "nudity"],
+    ["p", <pubkey>, "nudity"],
     ["L", "social.nos.ontology"],
     ["l", "NS-nud", "social.nos.ontology"]
   ],
@@ -60,8 +58,8 @@ Example events
 {
   "kind": 1984,
   "tags": [
-    ["e", "<eventId>", "illegal"],
-    ["p", "<pubkey>"]
+    ["e", <eventId>, "illegal"],
+    ["p", <pubkey>]
   ],
   "content": "He's insulting the king!",
   // other fields...
@@ -72,26 +70,13 @@ 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 an addressable event `kind:37375`.
+The wallet event is a parameterized replaceable 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 unspent proofs.
+Token events are used to record the unspent proofs that come from the mint.
 
 There can be multiple `kind:7375` events for the same mint, and multiple proofs inside each `kind:7375` event.
 
@@ -73,9 +73,7 @@ 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" ]
@@ -83,11 +81,8 @@ 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.
- * `.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.
@@ -101,7 +96,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-created-token>", "<relay-hint>", "created" ],
+        [ "e", "<event-id-of-spent-token>", "<relay-hint>", "created" ],
     ]),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ],
@@ -165,8 +160,7 @@ Her client:
             { "id": "1", "amount": 1 },
             { "id": "2", "amount": 2 },
             { "id": "4", "amount": 8 },
-        ],
-        "del": [ "event-id-1" ]
+        ]
     }),
     "tags": [
         [ "a", "37375:<pubkey>:my-wallet" ]
@@ -174,7 +168,6 @@ 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,11 +24,6 @@ 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
 [
@@ -42,8 +37,6 @@ 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",
@@ -55,8 +48,6 @@ 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",
@@ -68,7 +59,6 @@ Example:
     "fallback https://myotherserver.com/720/12345.m3u8",
     "fallback https://andanotherserver.com/720/12345.m3u8",
     "service nip96",
-    "duration 29.21"
   ],
 ]
 ```
@@ -82,6 +72,7 @@ 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
@@ -117,6 +108,7 @@ 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>"],

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

README.md

@@ -228,7 +228,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `31925`       | Calendar Event RSVP             | [52](52.md)                            |
 | `31989`       | Handler recommendation          | [89](89.md)                            |
 | `31990`       | Handler information             | [89](89.md)                            |
-| `32267`       | Software Application            |                                        |
 | `34235`       | Video Event                     | [71](71.md)                            |
 | `34236`       | Short-form Portrait Video Event | [71](71.md)                            |
 | `34550`       | Community Definition            | [72](72.md)                            |