Add a type field.
This commit is contained in:
parent
5c6e76a63b
commit
955160c750
1 changed files with 18 additions and 1 deletions
|
@ -20,10 +20,12 @@ to trust for membership. For example:
|
||||||
"join_rule": "restricted",
|
"join_rule": "restricted",
|
||||||
"allow": [
|
"allow": [
|
||||||
{
|
{
|
||||||
|
"type": "room-membership",
|
||||||
"room": "!mods:example.org",
|
"room": "!mods:example.org",
|
||||||
"via": ["example.org"]
|
"via": ["example.org"]
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
|
"type": "room-membership",
|
||||||
"room": "!users:example.org",
|
"room": "!users:example.org",
|
||||||
"via": ["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
|
allowed to join without an invite. Each entry is expected to be an object with the
|
||||||
following keys:
|
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.
|
* `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.
|
* `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`
|
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
|
||||||
|
@ -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,
|
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).
|
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
|
## Footnotes
|
||||||
|
|
||||||
<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
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue