Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-29 22:04:08 +02:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Space -> room.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-10 12:02:14 -04:00 committed by Richard van der Hoff
parent 963aa40665
commit 5c6e76a63b
1 changed files with 21 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -20,11 +20,11 @@ to trust for membership. For example:
"join_rule": "restricted", "join_rule": "restricted",
"allow": [ "allow": [
{ {
"space": "!mods:example.org", "room": "!mods:example.org",
"via": ["example.org"] "via": ["example.org"]
}, },
{ {
"space": "!users:example.org", "room": "!users:example.org",
"via": ["example.org"] "via": ["example.org"]
} }
] ]
@ -32,29 +32,29 @@ 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` room or
`!users:example.org` space in order to join without an invite<sup id="a2">[2](#f2)</sup>. `!users:example.org` room in order to join without an invite<sup id="a2">[2](#f2)</sup>.
Membership in a single space is enough. Membership in a single room is enough.
If the `allow` key is an empty list (or not a list at all), then no users are 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 allowed to join without an invite. Each entry is expected to be an object with the
following keys: following keys:
* `space`: The room ID of the space to check the membership of. * `room`: The room ID to check the membership of.
* `via`: A list of servers which may be used to peek for membership of the space. * `via`: A list of servers which may be used to peek for membership of the room.
Any entries in the list which do not match the expected format are ignored. Any entries in the list which do not match the expected format are ignored.
When a homeserver receives a `/join` request from a client or a `/make_join` / `/send_join` When a homeserver receives a `/join` request from a client or a `/make_join` / `/send_join`
request from a server, the request should only be permitted if the user has a valid request from a server, the request should only be permitted if the user has a valid
invite or is in one of the listed spaces. invite or is in one of the listed rooms.
If the user is not part of the proper space, the homeserver should return an error If the user is not a member of at least one of the rooms, the homeserver should
response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. return an error response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
It is possible for a homeserver receiving a `/make_join` / `/send_join` request It is possible for a homeserver receiving a `/make_join` / `/send_join` request
to not know if the user is in a particular space (due to not participating in any to not know if the user is in a particular room (due to not participating in any
of the necessary spaces). In this case the homeserver should reject the join, of the necessary rooms). In this case the homeserver should reject the join,
the requesting server may wish to attempt to join via other homeservers. the requesting server may wish to attempt to join via other homeservers.
Unlike the `invite` join rule, confirmation that the `allow` rules were properly Unlike the `invite` join rule, confirmation that the `allow` rules were properly
@ -108,22 +108,22 @@ described above.
Using an `allow` key with `invite` join rules to broaden who can join was rejected 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). 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 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 to `public` (since the checking of whether a member is in the room is done during
the call to `/join` or `/make_join` / `/send_join` regardless). the call to `/join` or `/make_join` / `/send_join` regardless).
## Future extensions ## Future extensions
### Checking space membership over federation ### Checking room 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 room (and thus doesn't know the membership of a room) it
cannot enforce membership of a space during a join. Peeking over federation, cannot enforce membership of a room during a join. Peeking over federation,
as described in [MSC2444](https://github.com/matrix-org/matrix-doc/pull/2444), as described in [MSC2444](https://github.com/matrix-org/matrix-doc/pull/2444),
could be used to establish if the user is in any of the proper spaces. could be used to establish if the user is in any of the proper rooms.
Note that there are additional security considerations with this, namely that Note that there are additional security considerations with this, namely that
the peek server has significant power. For example, a poorly chosen peek 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 room membership and add an `@evil_user:example.org`
to a space to gain membership to a room. to a room to gain membership to a room.
This MSC recommends rejecting the join in this case and allowing the requesting This MSC recommends rejecting the join in this case and allowing the requesting
homeserver to ask another homeserver. homeserver to ask another homeserver.
@ -145,7 +145,7 @@ were offline, other users in the room would still see Bob in the room (and their
servers would attempt to send message traffic to it). servers would attempt to send message traffic to it).
Another consideration is that users may have joined via a direct invite, not via Another consideration is that users may have joined via a direct invite, not via
access through a space. access through a room.
Fixing this is thorny. Some sort of annotation on the membership events might Fixing this is thorny. Some sort of annotation on the membership events might
help. but it's unclear what the desired semantics are: help. but it's unclear what the desired semantics are:
@ -172,7 +172,7 @@ as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
<a id="f1"/>[1]: The converse restriction, "anybody can join, provided they are not members <a id="f1"/>[1]: The converse restriction, "anybody can join, provided they are not members
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 room could simply leave it at any time
2. This functionality is already partially provided by 2. This functionality is already partially provided by
[Moderation policy lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1) [Moderation policy lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists). [↩](#a1)