From 157fe36b984e8b48f35809cbf354b1ceae22f969 Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Fri, 22 Nov 2024 13:40:33 -0800 Subject: [PATCH] Add feature detection for unmanaged groups --- 29.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) 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,