@ -34,10 +34,11 @@ to trust for membership. For example:
```
```
This means that a user must be a member of the `!mods:example.org` space or
This means that a user must be a member of the `!mods:example.org` space or
`!users:example.org` space in order to join without an invite<supid="a2">[2](#f2)</sup>. Membership in
`!users:example.org` space in order to join without an invite<supid="a2">[2](#f2)</sup>.
a single space is enough.
Membership in a single space is enough.
If the `allow` key is an empty list (or not a list at all), then no users are allowed to join without an invite. Each entry is expected to be an object with the
If the `allow` key is an empty list (or not a list at all), then no users are
allowed to join without an invite. Each entry is expected to be an object with the
following keys, or a string representing the MXID of the user exempted:
following keys, or a string representing the MXID of the user exempted:
* `space`: The room ID of the space to check the membership of.
* `space`: The room ID of the space to check the membership of.
@ -50,8 +51,8 @@ request from a server, the request should only be permitted if the user has a va
invite or is in one of the listed spaces. Note that the server may not know if the user
invite or is in one of the listed spaces. Note that the server may not know if the user
is in a particular space, this is left to a future MSC to solve.
is in a particular space, this is left to a future MSC to solve.
If the user is not part of the proper space, the homeserver should return an error response
If the user is not part of the proper space, the homeserver should return an error
with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
Unlike the `invite` join rule, confirmation that the `allow` rules were properly
Unlike the `invite` join rule, confirmation that the `allow` rules were properly
checked cannot be enforced over federation by event authorization, so servers in
checked cannot be enforced over federation by event authorization, so servers in
@ -60,7 +61,8 @@ However, user IDs listed as strings can be properly checked over federation.
### Discovery of restricted rooms
### Discovery of restricted rooms
The discovery of rooms in a space, as discussed in [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946): spaces summary,
The discovery of rooms in a space, as discussed in
must be updated to allow for discovery of restricted rooms.
must be updated to allow for discovery of restricted rooms.
MSC2946 defines that a room should be included in the spaces summary if it is
MSC2946 defines that a room should be included in the spaces summary if it is
@ -125,7 +127,8 @@ The `allow` feature for `join_rules` places increased trust in the servers in th
joining spurious users into your rooms, then:
joining spurious users into your rooms, then:
1. Don't let evil servers in your room in the first place
1. Don't let evil servers in your room in the first place
2. Don't use `allow` lists, given the expansion increases the attack surface anyway by letting members in other rooms dictate who's allowed into your room.
2. Don't use `allow` lists, given the expansion increases the attack surface anyway
by letting members in other rooms dictate who's allowed into your room.
## Unstable prefix
## Unstable prefix
@ -207,7 +210,8 @@ 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, as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
child rooms? Seems to have some of the same problems as inheriting power levels,
as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
Patrick Cloke
3 years ago