diff options
Diffstat (limited to '29.md')
| -rw-r--r-- | 29.md | 18 |
1 files changed, 1 insertions, 17 deletions
| @@ -48,14 +48,6 @@ The roles supported by the group as to having some special privilege assigned to | |||
| 48 | 48 | ||
| 49 | 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. | 49 | 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. |
| 50 | 50 | ||
| 51 | ## Unmanaged groups | ||
| 52 | |||
| 53 | 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. | ||
| 54 | |||
| 55 | In `unmanaged` groups, everybody is considered to be a member. | ||
| 56 | |||
| 57 | 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. | ||
| 58 | |||
| 59 | ## Event definitions | 51 | ## Event definitions |
| 60 | 52 | ||
| 61 | These are the events expected to be found in NIP-29 groups. | 53 | These are the events expected to be found in NIP-29 groups. |
| @@ -142,8 +134,6 @@ This event defines the metadata for the group -- basically how clients should di | |||
| 142 | 134 | ||
| 143 | 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. | 135 | 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. |
| 144 | 136 | ||
| 145 | When this event is not found, clients may still connect to the group, but treat it as having a different status, `unmanaged`, | ||
| 146 | |||
| 147 | ```jsonc | 137 | ```jsonc |
| 148 | { | 138 | { |
| 149 | "kind": 39000, | 139 | "kind": 39000, |
| @@ -231,7 +221,7 @@ The process through which the relay decides what roles to support and how to han | |||
| 231 | 221 | ||
| 232 | ### Checking your own membership in a group | 222 | ### Checking your own membership in a group |
| 233 | 223 | ||
| 234 | 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. | 224 | 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. |
| 235 | 225 | ||
| 236 | ### Adding yourself to a group | 226 | ### Adding yourself to a group |
| 237 | 227 | ||
| @@ -240,9 +230,3 @@ Anyone can send a `kind:9021` join request to a group. The relay may then genera | |||
| 240 | ### Storing your list of groups | 230 | ### Storing your list of groups |
| 241 | 231 | ||
| 242 | 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. | 232 | 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. |
| 243 | |||
| 244 | ### Using `unmanaged` relays | ||
| 245 | |||
| 246 | 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. | ||
| 247 | |||
| 248 | Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list. | ||