wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Add a type field.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-10 12:16:01 -04:00 • committed by Richard van der Hoff
parent 5c6e76a63b
commit 955160c750
1 changed files with 18 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -20,10 +20,12 @@ to trust for membership. For example:
"join_rule": "restricted",
"allow": [
{
"type": "room-membership",
"room": "!mods:example.org",
"via": ["example.org"]
},
{
"type": "room-membership",
"room": "!users:example.org",
"via": ["example.org"]
}
@ -40,10 +42,14 @@ 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:
* `type`: `"room-membership"` to describe that we are allowing access via room
membership. Future MSCs may define other types.
* `room`: The room ID to check the membership of.
* `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. Thus,
if all entries are invalid, the list behaves as if empty and all users without
an invite are rejected.
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
@ -167,6 +173,17 @@ If you make a parent space invite-only, should that (optionally?) cascade into
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).
### Additional allow types
Future MSCs may wish to define additional values for the `type` argument, potentially
restricting access via:
* MXIDs or servers.
* A shared secret (room password).
These are just examples are not fully thought through for this MSC, but it should
be possible to add these behaviors in the future.
## Footnotes
<a id="f1"/>[1]: The converse restriction, "anybody can join, provided they are not members