From c53d1383d296dce56c37c79685007799d6981da5 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Thu, 20 Mar 2025 11:18:29 +0100 Subject: [PATCH] Clarify the meaning of "public rooms" for policy lists Relates to: #633 Signed-off-by: Johannes Marbach --- content/client-server-api/modules/moderation_policies.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/client-server-api/modules/moderation_policies.md b/content/client-server-api/modules/moderation_policies.md index 2912d164..15a3a377 100644 --- a/content/client-server-api/modules/moderation_policies.md +++ b/content/client-server-api/modules/moderation_policies.md @@ -18,8 +18,9 @@ the entity making the decisions on filtering is best positioned to interpret the rules how it sees fit. Moderation policy lists are stored as room state events. There are no -restrictions on how the rooms can be configured (they could be public, -private, encrypted, etc). +restrictions on how the rooms can be configured in terms of +[join rules](#mroomjoin_rules), [history visibility](#room-history-visibility), +encryption, etc. There are currently 3 kinds of entities which can be affected by rules: `user`, `server`, and `room`. All 3 are described with