diff --git a/29.md b/29.md
index a2c8ef2..7cdbfa3 100644
--- a/29.md
+++ b/29.md
@@ -52,11 +52,9 @@ Users with any roles that have any privilege can be considered _admins_ in a bro
 
 ## 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.
+If a group doesn't have a kind `39000` metadata event, it is considered `unmanaged`. Events posted to `unmanaged` group MUST NOT be handled by relays in any special way.
 
-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.
+Relays that do not allow `unmanaged` groups MUST set `nip29.unmanaged` to `false` in their NIP 11 document. In this mode, events sent to non-existent groups MUST be rejected by the relay.
 
 ## Event definitions
 
@@ -144,8 +142,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,