From d63e39c4aff63222d6494c02dca95d9be69f0a1e Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 16 Jun 2021 14:12:00 -0400 Subject: [PATCH] Handle feedback from Travis. --- proposals/3083-restricted-rooms.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index ec2893b1..e3415cbe 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -8,9 +8,9 @@ their room based on the membership of one or more spaces from ## Proposal -A new `join_rule` (`restricted`) will be used to reflect a cross between `invite` -and `public` join rules. The content of the join rules would include the rooms -to trust for membership. For example: +In a future room version a new `join_rule` (`restricted`) will be used to reflect +a cross between `invite` and `public` join rules. The content of the join rules +would include the rooms to trust for membership. For example: ```json { @@ -21,12 +21,12 @@ to trust for membership. For example: "allow": [ { "type": "m.room_membership", - "room": "!mods:example.org", + "room_id": "!mods:example.org", "via": ["example.org"] }, { "type": "m.room_membership", - "room": "!users:example.org", + "room_id": "!users:example.org", "via": ["example.org"] } ] @@ -44,14 +44,14 @@ following keys: * `type`: `"m.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_id`: 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. Thus, if all entries are invalid, the list behaves as if empty and all users without an invite are rejected. -From the perspective of hee [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules), +From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules), the `restricted` join rule has the same behavior as `public`. Additional checks against the `allow` rules are performed during event generation, as described below.