More wrapping.

proposals/3083-restricted-rooms.md

@@ -34,10 +34,11 @@ to trust for membership. For example:
 ```
 
 This means that a user must be a member of the `!mods:example.org` space or
-`!users:example.org` space in order to join without an invite<sup id="a2">[2](#f2)</sup>. Membership in
-a single space is enough.
+`!users:example.org` space in order to join without an invite<sup id="a2">[2](#f2)</sup>.
+Membership in  a single space is enough.
 
-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
+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, or a string representing the MXID of the user exempted:
 
 * `space`: The room ID of the space to check the membership of.
@@ -50,8 +51,8 @@ request from a server, the request should only be permitted if the user has a va
 invite or is in one of the listed spaces. Note that the server may not know if the user
 is in a particular space, this is left to a future MSC to solve.
 
-If the user is not part of the proper space, the homeserver should return an error response
-with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
+If the user is not part of the proper space, the homeserver should return an error
+response  with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`.
 
 Unlike the `invite` join rule, confirmation that the `allow` rules were  properly
 checked cannot be enforced over federation by event authorization, so servers in
@@ -60,7 +61,8 @@ However, user IDs listed as strings can be properly checked over federation.
 
 ### Discovery of restricted rooms
 
-The discovery of rooms in a space, as discussed in [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946): spaces summary,
+The discovery of rooms in a space, as discussed in
+[MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946): spaces summary,
 must be updated to allow for discovery of restricted rooms.
 
 MSC2946 defines that a room should be included in the spaces summary if it is
@@ -125,7 +127,8 @@ The `allow` feature for `join_rules` places increased trust in the servers in th
   joining spurious users into your rooms, then:
 
 1. Don't let evil servers in your room in the first place
-2. Don't use `allow` lists, given the expansion increases the attack surface anyway by letting members in other rooms dictate who's allowed into your room.
+2. Don't use `allow` lists, given the expansion increases the attack surface anyway
+   by letting members in other rooms dictate who's allowed into your room.
 
 ## Unstable prefix
 
@@ -207,7 +210,8 @@ It is possible that completely different state should be kept, or a different
 ### Inheriting join rules
 
 If you make a parent space invite-only, should that (optionally?) cascade into
-child rooms? Seems to have some of the same problems as inheriting power levels, as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
+child rooms? Seems to have some of the same problems as inheriting power levels,
+as discussed in [MSC2962](https://github.com/matrix-org/matrix-doc/pull/2962).
 
 ## Footnotes