1 files changed, 21 insertions, 33 deletions

diff --git a/29.md b/29.md
index 601d63a..f39d4d8 100644
--- a/29.md
+++ b/29.md
@@ -4,7 +4,7 @@ NIP-29
 Relay-based Groups
 ------------------
 
-`draft` `optional`
+`draft` `optional` `relay`
 
 This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
 
@@ -48,14 +48,6 @@ The roles supported by the group as to having some special privilege assigned to
 
 Users with any roles that have any privilege can be considered _admins_ in a broad sense and be returned in the `kind:39001` event for a group.
 
-## Unmanaged groups
-
-Unmanaged groups are impromptu groups that can be used in any public relay unaware of NIP-29 specifics. They piggyback on relays' natural white/blacklists (or lack of) but aside from that are not actively managed and won't have any admins, group state or metadata events.
-
-In `unmanaged` groups, everybody is considered to be a member.
-
-Unmanaged groups can transition to managed groups, in that case the relay master key just has to publish moderation events setting the state of all groups and start enforcing the rules they choose to.
-
 ## Event definitions
 
 These are the events expected to be found in NIP-29 groups.
@@ -83,7 +75,7 @@ Any user can send a kind `9021` event to the relay in order to request admission
 }
 ```
 
-The optional `code` tag may be used by the relay to preauthorize acceptances in `closed` groups, together with the `kind:9009` `create-invite` moderation event.
+The optional `code` tag may be used by the relay to preauthorize acceptance, together with the `kind:9009` `create-invite` moderation event.
 
 - *leave request* (`kind:9022`)
 
@@ -120,21 +112,21 @@ Clients can send these events to a relay in order to accomplish a moderation act
 
 Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
 
-| 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`     |                                                |
+| kind | name            | tags                                                                             |
+| ---  | ---             | ---                                                                              |
+| 9000 | `put-user`      | `p` with pubkey hex and optional roles                                           |
+| 9001 | `remove-user`   | `p` with pubkey hex                                                              |
+| 9002 | `edit-metadata` | fields to be modified, and optionally `unrestricted`, `open`, `visible` `public` |
+| 9005 | `delete-event`  | `e` with event id hex                                                            |
+| 9007 | `create-group`  |                                                                                  |
+| 9008 | `delete-group`  |                                                                                  |
+| 9009 | `create-invite` | arbitrary `code`                                                                 |
 
 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.
 
 ### 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).
+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 (as stated by the [NIP-11](11.md) `"self"` pubkey) 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)
 
@@ -142,8 +134,6 @@ This event defines the metadata for the group -- basically how clients should di
 
 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.
 
-When this event is not found, clients may still connect to the group, but treat it as having a different status, `unmanaged`,
-
 ```jsonc
 {
   "kind": 39000,
@@ -153,14 +143,18 @@ When this event is not found, clients may still connect to the group, but treat
     ["name", "Pizza Lovers"],
     ["picture", "https://pizza.com/pizza.png"],
     ["about", "a group for people who love pizza"],
-    ["public"], // or ["private"]
-    ["open"] // or ["closed"]
+    ["private"],
+    ["closed"]
   ]
   // other fields...
 }
 ```
 
-`name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
+- `name`, `picture` and `about` are basic metadata for the group for display purposes.
+- `private` indicates that only members can _read_ group messages. Omitting this tag indicates that anyone can read group messages.
+- `restricted` indicates that only members can _write_ messages to the group. Omitting this tag indicates that anyone can send messages to the group.
+- `hidden` indicates that relays should hide group metadata from non-members. Omitting this tag indicates that anyone can request group metadata events.
+- `closed` indicates that join requests are ignored. Omitting this tag indicates that users can expect join requests to be honored.
 
 - *group admins* (`kind:39001`) (optional)
 
@@ -227,18 +221,12 @@ The process through which the relay decides what roles to support and how to han
 
 ### Checking your own membership in a group
 
-The latest of either `kind:9000` or `kind:9001` events present in a group should tell a user that they are currently members of the group or if they were removed. In case none of these exist the user is assumed to not be a member of the group -- unless the group is `unmanaged`, in which case the user is assumed to be a member.
+The latest of either `kind:9000` or `kind:9001` events present in a group should tell a user that they are currently members of the group or if they were removed. In case none of these exist the user is assumed to not be a member of the group.
 
 ### Adding yourself to a group
 
-When a group is `open`, anyone can send a `kind:9021` event to it in order to be added, then expect a `kind:9000` event to be emitted confirming that the user was added. The same happens with `closed` groups, except in that case a user may only send a `kind:9021` if it has an invite code.
+Anyone can send a `kind:9021` join request to a group. The relay may then generate a `kind:9000` event immediately, or defer that decision to an administator. If a group is `closed`, join requests are not honored unless they include an invite code.
 
 ### Storing your list of groups
 
 A definition for `kind:10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
-
-### Using `unmanaged` relays
-
-To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
-
-Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.