(as originally suggested in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962)),
It may seem that just having the `allow` key with `public` join rules is enough,
as suggested in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962),
but there are concerns that having a `public` join rule that is restricted may
but there are concerns that having a `public` join rule that is restricted may
cause issues if an implementation does not understand the semantics of the `allow`
cause issues if an implementation has not been updated to understand the semantics
keyword. Using an `allow` key with `invite` join rules also does not make sense as
of the `allow` keyword. This could be solved by introducing a new room version,
from the perspective of the auth rules, this is akin to `public` (since the checking
but in that case it seems clearer to introduce the `restricted` join rule, as
of whether a member is in the space is done during the call to `/join`
described above.
or `/make_join` / `/send_join`).
The above concerns about an implementation not understanding the semantics of `allow`
Using an `allow` key with `invite` join rules to broaden who can join was rejected
could be solved by introducing a new room version, but if this is done it seems clearer
as an option since it requires weakening the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules).
to just introduce a a new join rule - `restricted` - as described above.
From the perspective of the auth rules, the `restricted` join rule is identical
to `public` (since the checking of whether a member is in the space is done during
the call to `/join` or `/make_join` / `/send_join` regardless).
## Future extensions
## Future extensions
Potential future extensions which should not be designed out include, but are not
included in this MSC.
### Checking space membership over federation
### Checking space membership over federation
If a server is not in a space (and thus doesn't know the membership of a space) it
If a server is not in a space (and thus doesn't know the membership of a space) it
@ -131,6 +126,9 @@ the peek server has significant power. For example, a poorly chosen peek
server could lie about the space membership and add an `@evil_user:example.org`
server could lie about the space membership and add an `@evil_user:example.org`
to a space to gain membership to a room.
to a space to gain membership to a room.
This MSC recommends rejecting the join in this case and allowing the requesting
homeserver to ask another homeserver.
### Kicking users out when they leave the allowed space
### Kicking users out when they leave the allowed space
In the above example, suppose `@bob:server.example` leaves `!users:example.org`:
In the above example, suppose `@bob:server.example` leaves `!users:example.org`:
@ -167,7 +165,7 @@ It is possible that completely different state should be kept, or a different
### Inheriting join rules
### Inheriting join rules
If you make a parent space invite-only, should that (optionally?) cascade into
If you make a parent space invite-only, should that (optionally?) cascade into
child rooms? Seems to have some of the same problems as inheriting power levels,
child rooms? This would have some of the same problems as inheriting power levels,
as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
## Footnotes
## Footnotes
@ -176,7 +174,8 @@ as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
of the '#catlovers' space" is less useful since:
of the '#catlovers' space" is less useful since:
1. Users in the banned space could simply leave it at any time
1. Users in the banned space could simply leave it at any time
2. This functionality is already somewhat provided by [Moderation policy lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1)
2. This functionality is already partially provided by
Patrick Cloke
5 years ago
committed by