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),
It may seem that just having the `allow` key with `public` join rules is enough
(as originally 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
cause issues if an implementation does not understand the semantics of the `allow`
keyword. Using an `allow` key with `invite` join rules also does not make sense as
from the perspective of the auth rules, this is akin 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`).
cause issues if an implementation has not been updated to understand the semantics
of the `allow` keyword. This could be solved by introducing a new room version,
but in that case it seems clearer to introduce the `restricted` join rule, as
described above.
The above concerns about an implementation not understanding the semantics of `allow`
could be solved by introducing a new room version, but if this is done it seems clearer
to just introduce a a new join rule - `restricted` - as described above.
Using an `allow` key with `invite` join rules to broaden who can join was rejected
as an option since it requires weakening the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules).
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
Potential future extensions which should not be designed out include, but are not
included in this MSC.
### Checking space membership over federation
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`
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
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
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).
## 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:
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
3 years ago
committed by