A bit less passive.

pull/977/head
Patrick Cloke 4 years ago committed by Richard van der Hoff
parent 31cdf835b8
commit 963aa40665

@ -2,8 +2,7 @@
A desirable feature is to give room admins the power to restrict membership of 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 their room based on the membership of one or more spaces from
[MSC1772: spaces](https://github.com/matrix-org/matrix-doc/pull/1772), [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772), for example:
for example:
> members of the #doglovers space can join this room without an invitation<sup id="a1">[1](#f1)</sup> > members of the #doglovers space can join this room without an invitation<sup id="a1">[1](#f1)</sup>
@ -74,8 +73,8 @@ between `public`, `invite`, and `restricted`.
`server_acls`. See [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). `server_acls`. See [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403).
* `private`: This is reserved, but unspecified. * `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), * `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` but with the additional caveat that servers must check the `allow` rules before
rules before generating a `join` event (whether for a local or a remote user). generating a `join` event (whether for a local or a remote user).
## Security considerations ## Security considerations

Loading…
Cancel
Save