You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When `BUZZ_REQUIRE_RELAY_MEMBERSHIP=true`, every authenticated connection is checked against the
217
-
`relay_members` table. In today's single-community deployment this is the relay-wide member list; in multi-community mode the same rule is scoped to the host-derived community. Only pubkeys with a row for that community may use that community. The relay owner
218
-
is bootstrapped automatically from `RELAY_OWNER_PUBKEY` on startup.
216
+
Every authenticated connection is checked for a direct role in the
217
+
`relay_members` table. When `BUZZ_REQUIRE_RELAY_MEMBERSHIP=true`, pubkeys without
218
+
a qualifying row are denied; on an open relay they retain the normal open-relay
219
+
authority. In today's single-community deployment this is the relay-wide member
220
+
list; in multi-community mode the same rule is scoped to the host-derived
221
+
community. The relay owner is bootstrapped automatically from
222
+
`RELAY_OWNER_PUBKEY` on startup.
223
+
224
+
The `observer` role is directly provisioned and grants exactly
225
+
`messages:read`. Existing channel membership still determines which private
226
+
channel events it may read. It cannot delegate through NIP-OA or use event
227
+
submission, media, Git, huddle, GIF, workflow, membership, join, or leave
228
+
mutation paths. Observer pubkeys and their role are included in the relay's
229
+
kind:13534 membership snapshot, so observer identities are operational service
230
+
identities and must not be treated as secret.
219
231
220
232
### CLI: Managing Members
221
233
@@ -227,6 +239,7 @@ In a Docker Compose deployment, use `run.sh`:
0 commit comments