Clean-up intro paragraphs for redactions.

content/rooms/fragments/v11-redactions.md

@@ -1,14 +1,3 @@
----
----
-
-{{% added-in this=true %}} The top-level `origin`, `membership`, and `prev_state` properties
-are no longer protected from redaction. The [`m.room.create`](/client-server-api#mroomcreate)
-event now keeps the entire `content` property. The [`m.room.redaction`](/client-server-api#mroomredaction)
-event keeps the `redacts` property under `content`. The
-[`m.room.power_levels`](/client-server-api#mroompower_levels) event keeps the
-`invite` property under `content`.
-
-The full redaction algorithm follows.
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

content/rooms/fragments/v9-redactions.md

@@ -1,25 +1,3 @@
----
----
-
-{{% added-in this=true %}} [`m.room.member`](/client-server-api#mroommember) events
-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.
 
 Upon receipt of a redaction event, the server must strip off any keys
 not in the following list:

content/rooms/v11.md

@@ -22,6 +22,15 @@ events is no longer redacted, *but* will only contain the `signed` key after red
 
 ### Redactions
 
+{{% added-in this=true %}} The top-level `origin`, `membership`, and `prev_state` properties
+are no longer protected from redaction. The [`m.room.create`](/client-server-api#mroomcreate)
+event now keeps the entire `content` property. The [`m.room.redaction`](/client-server-api#mroomredaction)
+event keeps the `redacts` property under `content`. The
+[`m.room.power_levels`](/client-server-api#mroompower_levels) event keeps the
+`invite` property under `content`.
+
+The full redaction algorithm follows.
+
 {{% rver-fragment name="v11-redactions" withVersioning="true" %}}
 
 ## Server implementation components

content/rooms/v9.md

@@ -17,6 +17,27 @@ Clients which implement the redaction algorithm locally should refer to the
 
 ### Redactions
 
+{{% added-in this=true %}} [`m.room.member`](/client-server-api#mroommember) events
+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="v9-redactions" withVersioning="true" %}}
 
 ## Server implementation components