Specify room version 10: knock_restricted and int power levels

changelogs/client_server/newsfragments/1099.feature

@@ -0,0 +1 @@
+Add support for a new `knock_restricted` join rule in supported room versions, as per [MSC3787](https://github.com/matrix-org/matrix-spec-proposals/pull/3787).

changelogs/room_versions/newsfragments/1099.clarification

@@ -0,0 +1 @@
+Clarify that room versions 1 through 9 accept stringy power levels, as noted by [MSC3667](https://github.com/matrix-org/matrix-spec-proposals/pull/3667).

changelogs/room_versions/newsfragments/1099.feature.1

@@ -0,0 +1 @@
+Add room version 10 as per [MSC3604](https://github.com/matrix-org/matrix-spec-proposals/pull/3604).

changelogs/room_versions/newsfragments/1099.feature.2

@@ -0,0 +1 @@
+Enforce integer power levels in room version 10 as per [MSC3667](https://github.com/matrix-org/matrix-spec-proposals/pull/3667).

changelogs/room_versions/newsfragments/1099.feature.3

@@ -0,0 +1 @@
+Add a `knock_restricted` join rule supported by room version 10 as per [MSC3787](https://github.com/matrix-org/matrix-spec-proposals/pull/3787).

changelogs/server_server/newsfragments/1099.clarification

@@ -0,0 +1 @@
+Clarifies the historical handling of non-integer power levels.

content/client-server-api/_index.md

@@ -1969,6 +1969,13 @@ 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 rule
 is only expected to work in room versions [which support it](/rooms/#feature-matrix).
 
+{{% added-in v="1.3" %}} `knock_restricted`
+This room can be joined as though it was `restricted` *or* `knock`. If you
+interact with the room using knocking, the `knock` rule takes effect whereas
+trying to join the room without an invite applies the `restricted` join rule.
+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:
 
 ![membership-flow-diagram](/diagrams/membership.png)
@@ -1984,6 +1991,15 @@ The allowable state transitions of membership are:
 ##### Knocking on rooms
 
 {{% added-in v="1.1" %}}
+{{% changed-in v="1.3" %}}
+
+{{% boxes/note %}}
+As of `v1.3`, it is possible to knock on a [restricted room](#restricted-rooms)
+if the room supports and is using the `knock_restricted` join rule.
+
+Note that `knock_restricted` is only expected to work in room versions
+[which support it](/rooms/#feature-matrix).
+{{% /boxes/note %}}
 
 <!--
 This section is here because it's most similar to being invited/joining a
@@ -2021,6 +2037,15 @@ server chose to auto-accept.
 ##### Restricted rooms
 
 {{% added-in v="1.2" %}}
+{{% changed-in v="1.3" %}}
+
+{{% boxes/note %}}
+As of `v1.3`, it is possible to [knock](#knocking-on-rooms) on a restricted
+room if the room supports and is using the `knock_restricted` join rule.
+
+Note that `knock_restricted` is only expected to work in room versions
+[which support it](/rooms/#feature-matrix).
+{{% /boxes/note %}}
 
 Restricted rooms are rooms with a `join_rule` of `restricted`. These rooms
 are accompanied by "allow conditions" as described in the

content/rooms/_index.md

@@ -36,10 +36,11 @@ Alternatively, consider flipping the column/row organization to be features
 up top and versions on the left.
 -->
 
-| Feature \ Version | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
-|-------------------|---|---|---|---|---|---|---|---|---|
-| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ |
-| **Restricted join rules** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ |
+| Feature \ Version | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
+|-------------------|---|---|---|---|---|---|---|---|---|----|
+| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ | ✔ |
+| **Restricted join rules** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ |
+| **`knock_restricted` join rule** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ |
 
 ## Complete list of room versions
 
@@ -73,6 +74,8 @@ The available room versions are:
     of another room to join without invite.
 -   [Version 9](/rooms/v9) - **Stable**. Builds on v8 to fix issues when
     redacting some membership events.
+-   [Version 10](/rooms/v10) - **Stable**. Enforces integer-only power levels
+    and adds `knock_restricted` join rule.
 
 ## Room version grammar
 

content/rooms/fragments/v1-deprecated-formatting-off-spec.md

@@ -0,0 +1,13 @@
+---
+toc_hide: true
+---
+
+Events sent into rooms of this version can have formats which are different
+from their normal schema. Those cases are documented here.
+
+{{% boxes/warning %}}
+The behaviour described here is preserved strictly for backwards compatibility
+only. A homeserver should take reasonable precautions to prevent users from
+sending these so-called "malformed" events, and must never rely on the behaviours
+described here as a default.
+{{% /boxes/warning %}}

content/rooms/fragments/v1-stringy-power-levels.md

@@ -0,0 +1,24 @@
+---
+toc_hide: true
+---
+
+##### Power levels accepted as strings
+
+In order to maintain backwards compatibility with early implementations,
+power levels can optionally be represented in string format instead of
+integer format. A homeserver must be prepared to deal with this by parsing
+the power level from a string. In these cases, the following formatting of the
+power level string is allowed:
+
+* a single Base10 integer, no float values or decimal points, optionally with
+  any number of leading zeroes (`"100"`, `"000100"`);
+* optionally with any number of leading or trailing whitespace characters (`" 100 "`,
+  `" 00100 "`);
+* optionally prefixed with a single `-` or `+` character before the integer
+  but after leading whitespace padding (`" +100 "`, `" -100 "`, `"+100"`,
+  `"-100"`).
+
+{{% boxes/note %}}
+The integer represented by the string must still be within the `[-2^53, 2^53)`
+range accepted by normal, non-string, power level values.
+{{% /boxes/note %}}

content/rooms/fragments/v9-redactions.md

@@ -0,0 +1,50 @@
+---
+toc_hide: true
+---
+
+{{% boxes/rationale %}}
+Without the `join_authorised_via_users_server` property, redacted join events
+can become invalid when verifying the auth chain of a given event, thus creating
+a split-brain scenario where the user is able to speak from one server's
+perspective but most others will continually reject their events.
+
+This can theoretically be worked around with a rejoin to the room, being careful
+not to use the faulty events as `prev_events`, though instead it is encouraged
+to use v9 rooms over v8 rooms to outright avoid the situation.
+
+[Issue #3373](https://github.com/matrix-org/matrix-doc/issues/3373) has further
+information.
+{{% /boxes/rationale %}}
+
+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:
+
+-   `event_id`
+-   `type`
+-   `room_id`
+-   `sender`
+-   `state_key`
+-   `content`
+-   `hashes`
+-   `signatures`
+-   `depth`
+-   `prev_events`
+-   `prev_state`
+-   `auth_events`
+-   `origin`
+-   `origin_server_ts`
+-   `membership`
+
+The content object must also be stripped of all keys, unless it is one
+of one of the following event types:
+
+-   `m.room.member` allows keys `membership`, `join_authorised_via_users_server`.
+-   `m.room.create` allows key `creator`.
+-   `m.room.join_rules` allows keys `join_rule`, `allow`.
+-   `m.room.power_levels` allows keys `ban`, `events`, `events_default`,
+    `kick`, `redact`, `state_default`, `users`, `users_default`.
+-   `m.room.history_visibility` allows key `history_visibility`.

content/rooms/v1.md

@@ -48,6 +48,12 @@ Events in version 1 rooms have the following structure:
 
 {{% definition path="api/server-server/definitions/pdu" %}}
 
+#### Deprecated formatting
+
+{{% rver-fragment name="v1-deprecated-formatting-off-spec" %}}
+
+{{% rver-fragment name="v1-stringy-power-levels" %}}
+
 ### Authorization rules
 
 {{% rver-fragment name="v1-auth-rules" %}}