wipnip290-rpc-smells

1 files changed, 13 insertions, 7 deletions

diff --git a/29.md b/29.md
index 601d63a..8598113 100644
--- a/29.md
+++ b/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.