Update 94.md

Adding `duration` and `bitrate` to NIP-94 to cover NIP-71 content

29.md

@@ -122,29 +122,23 @@ 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 other than admins.
+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.
 
 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.
 

94.md

@@ -15,7 +15,7 @@ This NIP specifies the use of the `1063` event kind, having in `content` a descr
 * `url` the url to download the file
 * `m` a string indicating the data type of the file. The [MIME types](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types) format must be used, and they should be lowercase.
 * `x` containing the SHA-256 hexencoded string of the file.
-* `ox` containing the SHA-256 hexencoded string of the original file, before any transformations done by the upload server
+* `ox` (optional) containing the SHA-256 hexencoded string of the original file, before any transformations done by the upload server
 * `size` (optional) size of file in bytes
 * `dim` (optional) size of file in pixels in the form `<width>x<height>`
 * `magnet` (optional) URI to magnet file
@@ -27,6 +27,8 @@ This NIP specifies the use of the `1063` event kind, having in `content` a descr
 * `alt` (optional) description for accessibility
 * `fallback` (optional) zero or more fallback file sources in case `url` fails
 * `service` (optional) service type which is serving the file (eg. [NIP-96](96.md))
+* `duration` (optional) duration of media (video/audio) in seconds
+* `bitrate` (optional) average bitrate of media (video/audio) in bits/sec
 
 ```jsonc
 {

README.md

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