Room versions 8 and 9: Restricted rooms

content/client-server-api/_index.md

@@ -1748,11 +1748,11 @@ This room can only be joined if you were invited, and allows anyone to
 request an invite to the room. Note that this join rule is only available
 in room versions [which support knocking](/rooms/#feature-matrix).
 
-`restricted`
+{{% added-in v="1.2" %}} `restricted`
 This room can be joined if you were invited or if you are a member of another
 room listed in the join rules. If the server cannot verify membership for any
-of the listed rooms then you can only join with an invite. Note that this join
-rule is only available in room versions [which support it](/rooms/#feature-matrix).
+of the listed rooms then you can only join with an invite. Note that this rule
+is only expected to work in room versions [which support it](/rooms/#feature-matrix).
 
 The allowable state transitions of membership are:
 
@@ -1805,6 +1805,8 @@ server chose to auto-accept.
 
 ##### Restricted rooms
 
+{{% added-in v="1.2" %}}
+
 Restricted rooms are rooms with a `join_rule` of `restricted`. These rooms
 are accompanied by "allow conditions" as described in the
 [`m.room.join_rules`](#mroomjoin_rules) state event.
@@ -1820,9 +1822,10 @@ before accepting the join. See the [Server-Server Spec](/server-server-api/#rest
 for more information.
 
 If the room is `restricted` but no valid conditions are presented then the
-room is effectively invite only. The user does not need to maintain the
-conditions in order to stay a member of the room: the conditions are only
-checked/evaluated during the join process.
+room is effectively invite only.
+
+The user does not need to maintain the conditions in order to stay a member
+of the room: the conditions are only checked/evaluated during the join process.
 
 ###### Conditions
 

content/rooms/fragments/v8-auth-rules.md

@@ -44,7 +44,7 @@ The rules are as follows:
     reject.
 4.  If type is `m.room.member`:
     1.  If no `state_key` key or `membership` key in `content`, reject.
-    2.  If `content` has `join_authorised_via_users_server`
+    2.  If `content` has a `join_authorised_via_users_server`
         key:
         1.  If the event is not validly signed by the user ID denoted
             by the key, reject.

content/rooms/v7.md

@@ -199,6 +199,10 @@ completeness.
 
 {{% rver-fragment name="v4-event-format" %}}
 
+### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ### Canonical JSON
 
 {{% rver-fragment name="v6-canonical-json" %}}
@@ -209,6 +213,4 @@ completeness.
 
 ### Redactions
 
-{{% rver-fragment name="v3-handling-redactions" %}}
-
 {{% rver-fragment name="v6-redactions" %}}

content/rooms/v8.md

@@ -25,31 +25,9 @@ The new join rule, `restricted`, is described in the
 Clients which implement the redaction algorithm locally should refer to the
 [redactions](#redactions) section below for a full overview.
 
-## Server implementation components
-
-{{% boxes/warning %}}
-The information contained in this section is strictly for server
-implementors. Applications which use the Client-Server API are generally
-unaffected by the intricacies contained here. The section above
-regarding client considerations is the resource that Client-Server API
-use cases should reference.
-{{% /boxes/warning %}}
-
-Room version 8 adds a new join rule to allow members of a room to join another
-room without invite. Otherwise, the room version inherits all properties of
-[Room version 7](/rooms/v7).
-
-### Authorization rules
-
-{{% added-in this=true %}} For checks performed upon `m.room.member` events, new
-points for handling `content.join_authorised_via_users_server` are added (Rule 4.2
-and 4.3.5).
-
-{{% rver-fragment name="v8-auth-rules" %}}
-
 ### Redactions
 
-{{% added-in this=true %}} `m.room.join_rules` now keep `allow` in addition to other
+{{% added-in this=true %}} `m.room.join_rules` events now keep `allow` in addition to other
 keys in `content` when being redacted.
 
 {{% boxes/warning %}}
@@ -60,8 +38,6 @@ v8 when creating new rooms.
 
 The full redaction algorithm follows.
 
-{{% rver-fragment name="v3-handling-redactions" %}}
-
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:
 
@@ -91,6 +67,32 @@ of one of the following event types:
     `kick`, `redact`, `state_default`, `users`, `users_default`.
 -   `m.room.history_visibility` allows key `history_visibility`.
 
+## Server implementation components
+
+{{% boxes/warning %}}
+The information contained in this section is strictly for server
+implementors. Applications which use the Client-Server API are generally
+unaffected by the intricacies contained here. The section above
+regarding client considerations is the resource that Client-Server API
+use cases should reference.
+{{% /boxes/warning %}}
+
+Room version 8 adds a new join rule to allow members of a room to join another
+room without invite. Otherwise, the room version inherits all properties of
+[Room version 7](/rooms/v7).
+
+### Authorization rules
+
+{{% added-in this=true %}} For checks performed upon `m.room.member` events, new
+points for handling `content.join_authorised_via_users_server` are added (Rule 4.2
+and 4.3.5).
+
+{{% rver-fragment name="v8-auth-rules" %}}
+
+### Redactions
+
+[See above](#redactions).
+
 ## Unchanged from v7
 
 The following sections have not been modified since v7, but are included for
@@ -108,6 +110,10 @@ completeness.
 
 {{% rver-fragment name="v4-event-format" %}}
 
+### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ### Canonical JSON
 
 {{% rver-fragment name="v6-canonical-json" %}}

content/rooms/v9.md

@@ -15,20 +15,6 @@ restricted rooms.
 Clients which implement the redaction algorithm locally should refer to the
 [redactions](#redactions) section below for a full overview.
 
-## Server implementation components
-
-{{% boxes/warning %}}
-The information contained in this section is strictly for server
-implementors. Applications which use the Client-Server API are generally
-unaffected by the intricacies contained here. The section above
-regarding client considerations is the resource that Client-Server API
-use cases should reference.
-{{% /boxes/warning %}}
-
-Room version 8 added a new `restricted` join rule to allow members of a room
-to join another room without invite. Room version 9 is based upon v8 with the
-following considerations.
-
 ### Redactions
 
 {{% added-in this=true %}} `m.room.member` now keep `join_authorised_via_users_server`
@@ -81,6 +67,24 @@ of one of the following event types:
     `kick`, `redact`, `state_default`, `users`, `users_default`.
 -   `m.room.history_visibility` allows key `history_visibility`.
 
+## Server implementation components
+
+{{% boxes/warning %}}
+The information contained in this section is strictly for server
+implementors. Applications which use the Client-Server API are generally
+unaffected by the intricacies contained here. The section above
+regarding client considerations is the resource that Client-Server API
+use cases should reference.
+{{% /boxes/warning %}}
+
+Room version 8 added a new `restricted` join rule to allow members of a room
+to join another room without invite. Room version 9 is based upon v8 with the
+following considerations.
+
+### Redactions
+
+[See above](#redactions).
+
 ## Unchanged from v8
 
 The following sections have not been modified since v8, but are included for
@@ -102,6 +106,10 @@ completeness.
 
 {{% rver-fragment name="v4-event-format" %}}
 
+### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ### Canonical JSON
 
 {{% rver-fragment name="v6-canonical-json" %}}

content/server-server-api.md

@@ -721,8 +721,8 @@ The joining server is expected to add or replace the `origin`,
 `origin_server_ts`, and `event_id` on the templated event received by
 the resident server. This event is then signed by the joining server.
 
-To complete the join handshake, the joining server must now submit this
-new event to a resident homeserver, by using the `PUT /send_join`
+To complete the join handshake, the joining server submits this new event
+to the resident server it used for `GET /make_join`, using the `PUT /send_join`
 endpoint.
 
 The resident homeserver then adds its signature to this event and

data/event-schemas/schema/m.room.join_rules.yaml

@@ -26,6 +26,7 @@ properties:
           - restricted
         type: string
       allow:
+        x-addedInMatrixVersion: "1.2"
         description: |-
           For `restricted` rooms, the conditions the user will be tested against. The
           user needs only to satisfy one of the conditions to join the `restricted`

data/event-schemas/schema/m.room.member.yaml

@@ -70,8 +70,10 @@ properties:
           Usually found on `join` events, this field is used to denote which homeserver (through representation of a user with sufficient power level)
           authorised the user's join. More information about this field can be found in the [Restricted Rooms Specification](#restricted-rooms).
 
-          Client and server implementations should be aware of the [signing implications](/rooms/v8/#authorization-rules-for-events) of including this
-          field in further events: when copying the membership event's `content` (for profile updates and similar) it is encouraged to exclude this
+          Client and server implementations should be aware of the [signing implications](/rooms/v8/#authorization-rules) of including this
+          field in further events: in particular, the event must be signed by the server which
+          owns the user ID in the field. When copying the membership event's `content` 
+          (for profile updates and similar) it is therefore encouraged to exclude this
           field in the copy, as otherwise the event might fail event authorization.
       reason:
         x-addedInMatrixVersion: "1.1"

static/diagrams/membership.drawio

@@ -1 +1 @@
-<mxfile host="app.diagrams.net" modified="2021-04-28T19:35:50.494Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36" etag="-IOh23FjJiPnGlGWLseU" version="14.6.6" type="device"><diagram id="4a_pTli-mcEMNPq0ciXK" name="Page-1">3Vvdb6M4EP9rIt09NMIGA3ncZtvbh73TSn243X1ZOYmT0BIcOaZJ9q8/E0z4cggEgulVqoqHsbHHv/nwjDsyp5vDXwxv13/TBfFH0FgcRubnEYTAAa74E1GOMWViopiwYt5CMqWEF+83kURDUkNvQXY5Rk6pz71tnjinQUDmPEfDjNF9nm1J/fxXt3hFSoSXOfbL1H+9BV/HVBc6Kf0L8Vbr5MvAnsRvNjhhlivZrfGC7jMk82lkThmlPH7aHKbEj4SXyCXu93zh7XlijAS8TodvBvr96euj/xL83G+Dn2gaTvgDkMO8Yz+UKxYjvFIvkJPmx0QSZCEEI5uU8TVd0QD7Tyn1kdEwWJDoc4ZopTxfKd0KIhDEV8L5Ue4yDjkVpDXf+PJt/M3oQxfXKEk7GrI5qVqYxApmK8Ir+OB5JwSECd0Qzo6iHyM+5t57fh5YYml15pNdPzGGjxmGrZAf32VG/hYRBINUCziRmJBKYdqFrWvGLx7iGSStzFJS0gkOTaBhqaDhEyykogEb5ODx75nnH9FQY4hk8/NBDn1qHJNGIGTwPcMZtX9kX6b9Tq2kY4dIhKgmFC01FCUGjDEwHDMeqhk6S3Cy3DycoDUZ25kfx8qPGM9cDpLCrinqLVD4rG1Wot4CqIo/j/q0dzIdulzuCC/06EYzSorhBe8eL6tFHvT7teB52eITWvbCXaqM3zthnByqQXcRI9ApSBjJ9j51XcCQtHXGbSV8KgzlpNdYVHaFETEoG0VO6/nNm799cH8DO1JysRduOyW/P/4hVG3qDGuJGRK/YIxRxjOA29wC6NEt1ASMWQmYB2NsI6ulW+gBMSXAKEPMRvZySQP+jDeeH23OVIjbI5E5+Yfs72NMLUu7MXVVehcGujUvF5HVDMhAVu1kr34Uz2xnqWsrWautNks7rdrkQekLQoVDiqldX5R+KrY8hreMVhfOfG8+grYv5vI4E/KwV9FTxPOLhT7Z6XVp8Caf5ug66lg1VavtobsdKsq6Jca5EMH3sduXNq7HYKT2xqFr0QgaeigCnEEGr05W0426mq4tqVEXMBei1340vZzAUmevBuVGzWKuT7sbVUadGu1lO53RFnfCSWdG1rVdq52dPddnCgkjB+WHiFdVSv31arCNjx3F5RPW1ccjLXBraaLrIcuy6yGrs4yDsrCly82nHrtRhHdLbksHhK7mqFxogrsYLGTVg1XTWgUo1CqQWV2hs41Kfn21CqhMwA/Ae9+SNGp6tM3Fal+I/064N8cdK0lHZycRzN+iIU2BbVr5ohqYoIEAVXkuG0qlqGWV4eOitrpeJUy7A4ZffjAHFQzcEBf+L6B0NUpwEGoZJfRgpspJhbeAKozSoJMK5zBKW1IhuRXT8SWKvouC+m9YJEF6RpBPB06YMEknl1k8FP8R0JOmiN8N2cwI+7NC4qChxMsmpl1JqXCGVKXCoELY9r2EbSpzEdIAxMmIU+MBz4QwB5qQKJSVaiebu/E8r+Fmmyw0oAFJSPGsHV1JkKtxjuvCm3JuTQP0wt08YFUfPM+3EtT8Gi/Jle2S/pjrVug3O3ZmIY7ZvGNI171OejXcmvRy4ISTwoETXcmkwEr+ewBaNNNr+DF7+s8M5tN/</diagram></mxfile>
+<mxfile host="Electron" modified="2022-01-10T02:42:21.552Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/16.1.2 Chrome/96.0.4664.55 Electron/16.0.5 Safari/537.36" etag="528W4E-DZvXgHQKcGR3G" version="16.1.2" type="device"><diagram id="4a_pTli-mcEMNPq0ciXK" name="Page-1">1VtLb9s4EP41BnYPMSTq6WPjJu2huyiQw7a9FLRM20ok0aApP/rrl7LI6MUoomQ9EiCBOBpS4vCbmY9DZWYsw/MXAve7f/AaBTOgrc8z4/MMAFe32N9EcEkFuga4ZEv8NZdlgif/DxKKXBr7a3QoKFKMA+rvi0IPRxHyaEEGCcGnotoGB8Wn7uEWVQRPHgyq0v/8Nd3xeQEnk39F/nYnnqzbi/ROCIUyn8lhB9f4lBMZDzNjSTCm6VV4XqIgMZ6wS9rv8Y27ry9GUESbdPiuWX8+fbsPnqJfp330y1rGC3qn82GOMIj5jNkIz9iP+EvTi7AEWjPD8CYmdIe3OILBQya9JziO1ih5nMZamc43jPdMqDPhM6L0wlcZxhQz0Y6GAb9bnRJ/vQOOiYfq5sGhAckW0Ro9kOolc8k9gBvsC8IhouTCFAgKIPWPRRBAjqXtqx7v+okQeMkp7Jn96CE38vdEwBS4W4AFxwT3CsMuLZ2aPrtI30C0clPJRFc4qEDDlEEjQJBZZQRsoLNPf+SufyZDzVk0SZufz3zoa+MiGhGzwY+cZtL+mb+Z9bu2RMf2SBTx7V0omg2hyDGgzXXNMdI+auiswMl0i3AC5mJu534cszhiOhU+SAY7VdSbeumxtlGLelMkD7l+EfVZb/E6eLM5IFrqcRvPqDiGHx19WnWLIuhPO6bztIdX+JxYumwY/I6IUHRughHglCxs8fYpS126xmW7XNoSejIMFaynbCq7JohomMySpPX44nsvHyvfgL6cnK2F283J+8c/ALJFXcFROIPIC9rcymUGvV1a0PtLCw0BY6gB5k6b25bZMS0MgJgKYKQUUylebnBEH2HoB8niLJn9fZSEk3/RqZ9gapqjB1NX5ndxNLbnFRhZQ0Km592O9+rF8YwbR+rGTtZpqY3KSssWeVL+YlmlTYoxur9I81QaeTR/k0w4XgW+NwN2wN7lfsXsYW+Tq0TnN4kDdBg3pYFWOc0ZaKtjNnStm2+6u6Gi6ltsnDcY/BCr/dbC9UdGGi+cpcxGrKlTEd2ZJHl18p6uNfX0oYoaTQHTlL0O4+nVApa8ejWpNGqUa32jp1Ep6xwxXnbzmaF4J1j0F2Rd2zW7xVkBxXLByLGKQ6TTrJT+Bg3Y2nssDgYBPjFIVWjcKjFbnsuVFf4SBHCZLAD1/h4T0MXKdv0+aghc3jqWN4OgaTeD4M1KE9ITsLH4QJbalahgmyLYABBSL2a5wNB7iWyW2QxWqocaeulQwzLqj/JsrVZ/vEMNIK3UTyDNt6kuqe6BC6TuKwqOiPoe7OYkfW2yGOtv4yGqwDbM4umbvrAmAlTpBm4qR0odjyM+DGoVD7ZYaHf06Z9TGJMiAy144UeEkjpLcCyrI0sYIExVqw8vEZYEpUlXH15p1GjVB5Eeb/y1xdCnh+N/iiFYe86QD2eKCAtJ15RZ2RtH+Oop7DdE4QqR6uY4s7iuaPFGIUbh7Km0h5TVzIDE2HZfxjakRQseANKqxbVxB1fMmB/j/KlxVfo2mec5DvdiohGOkBClb+0MVARR5zmuC1oV51QJeukjPt2s33i+fr4g1x/xa7pqXBqfc7WFvtq2Mw9xSLxukG763ak63VoMsuEEi9KG03qnkgJq9fsANGtm3+un6tl/PRgP/wM=</diagram></mxfile>