|
|
@ -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)
|
|
|
|
|
|
|
|
|
|
|
|