Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-10 01:43:43 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

More wrapping.

Browse source
This commit is contained in:
Patrick Cloke 2021-05-12 11:16:27 -04:00 committed by Richard van der Hoff
parent 933c50480c
commit 35ce0b8f91
1 changed files with 12 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
proposals/3083-restricted-rooms.md
View file

@ -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
`!users:example.org` space in order to join without an invite<sup id="a2">[2](#f2)</sup>. Membership in
a single space is enough.
`!users:example.org` space in order to join without an invite<sup id="a2">[2](#f2)</sup>.
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:
* `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
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
with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
If the user is not part of the proper space, the homeserver should return an error
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
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
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
[MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946): spaces summary,
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
@ -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:
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
@ -207,7 +210,8 @@ 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, 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).
## Footnotes