Review feedback.

proposals/3083-restricted-rooms.md

@@ -63,45 +63,35 @@ if the user is invited to this room, or is joined to one of the listed rooms. If
 the user is not a member of at least one of the rooms, the homeserver should return
 an error response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
 
-It is possible for a resident homeserver (one which receives a `/make_join` /
-`/send_join` request) to not know if the user is in some of the allowed rooms (due
-to not participating in them). If the user is not in any of the allowed rooms that
-are known to the homeserver it should return an error response with HTTP status code
-of 400 with an `errcode` of `M_UNABLE_TO_AUTHORISE_JOIN`. The joining server should
-attempt to join via another resident homeserver. If the resident homeserver knows
-that the user is not in *any* of the allowed rooms it should return an error response
-with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. Note that it is a
-configuration error if there are allowed rooms with no participating authorised
-servers.
-
-A chosen resident homeserver might also be unable to issue invites; in this case
-it should return an error response with HTTP status code of 400 and an `errcode`
-of `M_CANNOT_ALLOW`. The joining server should attempt to join via another
-resident homeserver.
-
 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`, with the additional
 caveat that servers must ensure that:
 
 * The user's previous membership was `invite` or `join`, or
-* The join event has a valid signature
-  from a homeserver whose users have the power to issue invites. This implies
-  that:
+* The join event has a valid signature from a homeserver whose users have the
+  power to issue invites.
+
+  When generating a join event the server should include the MXID of a local user
+  who could issue an invite in the content with the key
+  `join_authorised_via_users_server`. The actual user chosen is arbitrary.
+
+  This implies that:
 
     * A join event issued via `/send_join` is signed by not just the requesting
       server, but also the resident server.<sup id="a3">[3](#f3)</sup>
 
       In order for the joining server to receive the proper signatures the join
       event will be returned via `/send_join` in the `event` field.
-    * The auth chain of the join event needs to include an event which proves
-      the homeserver can be issuing the join. This can be done by including the
-      `m.room.power_levels` event and an `m.room.member` event with `membership`
-      equal to `join` for a member who could issue invites from that server.
+    * The auth chain of the join event needs to include events which prove
+      the homeserver can be issuing the join. This can be done by including:
 
-      In order to find a corresponding event quickly for verification, the
-      content of the join event should include the chosen user's MXID in the
-      content with the key `join_authorised_via_users_server`. The actual user
-      chosen is arbitrary.
+      * The `m.room.power_levels` event
+      * The `m.room.member` event (with `membership` equal to `join`) the user
+        specified in `join_authorised_via_users_server`.
+
+      It should be confirmed that the authorising user is in the room. (This
+      prevents situations where any homeserver could process the join, even if
+      they weren't in the room, under certain power level conditions.)
 
       This creates a new restriction on the relationship between the resident
       servers used for `/make_join` and `/send_join` -- they must now both go to
@@ -113,6 +103,22 @@ Note that the homeservers whose users can issue invites are trusted to confirm
 that the `allow` rules were properly checked (since this cannot easily be
 enforced over federation by event authorisation).<sup id="a4">[4](#f4)</sup>
 
+It is possible for a resident homeserver (one which receives a `/make_join` /
+`/send_join` request) to not know if the user is in some of the allowed rooms (due
+to not participating in them). If the user is not in any of the allowed rooms that
+are known to the homeserver it should return an error response with HTTP status code
+of 400 with an `errcode` of `M_UNABLE_TO_AUTHORISE_JOIN`. The joining server should
+attempt to join via another resident homeserver. If the resident homeserver knows
+that the user is not in *any* of the allowed rooms it should return an error response
+with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. Note that it is a
+configuration error if there are allowed rooms with no participating authorised
+servers.
+
+A chosen resident homeserver might also be unable to issue invites; in this case
+it should return an error response with HTTP status code of 400 and an `errcode`
+of `M_CANNOT_ALLOW`. The joining server should attempt to join via another
+resident homeserver.
+
 To better cope with joining via aliases, homeservers should use the list of
 authorised servers (not the list of candidate servers) when a user attempts to
 join a room.