Copy/paste v9 into v10

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 |
+| Feature \ Version | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
-|-------------------|---|---|---|---|---|---|---|---|---|
+|-------------------|---|---|---|---|---|---|---|---|---|----|
-| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ |
+| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ | ✔ |
-| **Restricted join rules** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ |
+| **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/v9-redactions.md

@@ -0,0 +1,53 @@
+---
+toc_hide: true
+---
+
+{{% added-in this=true %}} `m.room.member` now keep `join_authorised_via_users_server`
+in addition to other keys in `content` when being redacted.
+
+{{% 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/v10.md

@@ -0,0 +1,90 @@
+---
+title: Room Version 10
+type: docs
+weight: 100
+---
+
+This room version builds on [version 9](/rooms/v9) to enforce that power level
+values be integers, and to introduce a new `knock_restricted` join rule, allowing
+prospective members to more easily join such a room.
+
+## Client considerations
+
+This room version adds a new `knock_restricted` join rule to allow prospective
+members of a room join either through knocking (introduced in [room version 7](/rooms/v7))
+or through "join restrictions" (introduced in [room version 8](/rooms/v8) and
+refined in [room version 9](/rooms/v9)).
+
+Clients should render the new join rule accordingly for such 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 7](/rooms/v7) added "knocking" and [room version 8](/rooms/v8)
+added "join restrictions" (refined by [room version 9](/rooms/v9)) - both allow
+prospective members an avenue to join, however both could not be used at the
+same time due to how the join rules work. This room version adds a new
+`knock_restricted` join rule as a mix of the two behaviours (first match wins).
+
+This room version additionally requires that values in the power levels event
+be integers and not string representations, unlike other room versions.
+
+Room version 10 is based upon room version 9 with the following considerations.
+
+### TODO
+
+* Auth rules
+* Stringy power levels
+
+## Unchanged from v9
+
+The following sections have not been modified since v9, but are included for
+completeness.
+
+### Redactions
+
+{{% rver-fragment name="v9-redactions" %}}
+
+### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
+### Event IDs
+
+{{% rver-fragment name="v4-event-ids" %}}
+
+### Event format
+
+{{% rver-fragment name="v4-event-format" %}}
+
+#### Deprecated formatting
+
+{{% rver-fragment name="v1-deprecated-formatting-off-spec" %}}
+
+{{% rver-fragment name="v1-stringy-power-levels" %}}
+
+### Authorization rules
+
+{{% rver-fragment name="v8-auth-rules" %}}
+
+### State resolution
+
+{{% rver-fragment name="v2-state-res" %}}
+
+### Canonical JSON
+
+{{% rver-fragment name="v6-canonical-json" %}}
+
+### Signing key validity period
+
+{{% rver-fragment name="v5-signing-requirements" %}}

content/rooms/v9.md

@@ -17,55 +17,7 @@ Clients which implement the redaction algorithm locally should refer to the
 
 ### Redactions
 
-{{% added-in this=true %}} `m.room.member` now keep `join_authorised_via_users_server`
+{{% rver-fragment name="v9-redactions" %}}
-in addition to other keys in `content` when being redacted.
-
-{{% 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`.
 
 ## Server implementation components