From 963aa4066579756a865c8b001b28a66086b35a52 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 4 Jun 2021 08:57:41 -0400 Subject: [PATCH] A bit less passive. --- proposals/3083-restricted-rooms.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index 62d4029c..b3daba6d 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -2,8 +2,7 @@ A desirable feature is to give room admins the power to restrict membership of their room based on the membership of one or more spaces from -[MSC1772: spaces](https://github.com/matrix-org/matrix-doc/pull/1772), -for example: +[MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772), for example: > members of the #doglovers space can join this room without an invitation[1](#f1) @@ -74,8 +73,8 @@ between `public`, `invite`, and `restricted`. `server_acls`. See [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). * `private`: This is reserved, but unspecified. * `restricted`: the same as `public` from the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules), - but with the additional caveat that servers are expected to check the `allow` - rules before generating a `join` event (whether for a local or a remote user). + but with the additional caveat that servers must check the `allow` rules before + generating a `join` event (whether for a local or a remote user). ## Security considerations