Try to clarify redactions a bit

content/client-server-api/_index.md

@@ -1598,7 +1598,8 @@ content from the databases. Servers should include a copy of the
 when serving the redacted event to clients.
 
 The exact algorithm to apply against an event is defined in the [room
-version specification](/rooms).
+version specification](/rooms), as are the acceptance criteria for a
+redaction event.
 
 When a client receives an `m.room.redaction` event, it should change
 the affected event in the same way a server does.

content/rooms/fragments/v3-auth-rules.md

@@ -1,9 +1,16 @@
-In room versions 1 and 2, events need a signature from the domain of
-the `event_id` in order to be considered valid. This room version does
-not include an `event_id` over federation in the same respect, so does
-not need a signature from that server. The event must still be signed by
+In room versions 1 and 2, events need a signature from the domain of the
+`event_id` in order to be considered valid. This room version does not
+include an `event_id` over federation in the same respect, so does not
+need a signature from that server. The event must still be signed by
 the server denoted by the `sender`, however.
 
+{{% added-in this=true %}} `m.room.redaction` events are no longer
+explicitly part of the auth rules. They are still subject to the
+minimum power level rules, but should always fall into "11. Otherwise,
+allow". Instead of being authorized at the time of receipt, they are
+authorized at a later stage: see the [Handling Redactions](#handling-redactions)
+section below for more information.
+
 The types of state events that affect authorization are:
 
 -   `m.room.create`
@@ -131,28 +138,6 @@ The complete list of rules, as of room version 3, is as follows:
     6.  Otherwise, allow.
 11. Otherwise, allow.
 
-{{% boxes/note %}}
-
-{{% added-in this=true %}} `m.room.redaction` events are no longer
-explicitly part of the above rules. They are still subject to the
-minimum power level rules, but should always fall into "11. Otherwise,
-allow".
-
-Redactions should only be sent to clients once both the redaction and
-redacted event are received and validated by the server. If both events
-are valid and have been seen by the server, then the server applies the
-redaction if one of the following conditions is met:
-
-1. The power level of the redaction event's `sender` is greater than or
-   equal to the *redact level*.
-2. The domain of the redaction event's `sender` matches that of the
-   original event's `sender`.
-
-If the server would apply a redaction, the redaction event is also sent
-to clients. Otherwise, the server simply waits for a valid partner event
-to arrive where it can then re-check the above.
-{{% /boxes/note %}}
-
 {{% boxes/note %}}
 Some consequences of these rules:
 

content/rooms/fragments/v3-handling-redactions.md

@@ -0,0 +1,20 @@
+In room versions 1 and 2, redactions were explicitly part of the
+[authorization rules](/rooms/v1/#authorization-rules) under Rule 11.
+As of room version 3, these conditions no longer exist as represented
+by the above rules.
+
+While redactions are always accepted by the authorization rules for
+events, they should not be sent to clients until both the redaction
+event and the event the redaction affects have been received, and can
+be validated. If both events are valid and have been seen by the server,
+then the server applies the redaction if one of the following conditions
+is met:
+
+1. The power level of the redaction event's `sender` is greater than or
+   equal to the *redact level*.
+2. The domain of the redaction event's `sender` matches that of the
+   original event's `sender`.
+
+If the server would apply a redaction, the redaction event is also sent
+to clients. Otherwise, the server simply waits for a valid partner event
+to arrive where it can then re-check the above.

content/rooms/v3.md

@@ -84,6 +84,12 @@ room version during a request.
 <!-- set withVersioning=true so we get all the "new in this version" stuff -->
 {{% rver-fragment name="v3-auth-rules" withVersioning=true %}}
 
+#### Handling redactions
+
+{{% added-in this=true %}}
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ## Unchanged from v2
 
 The following sections have not been modified since v2, but are included for

content/rooms/v4.md

@@ -63,6 +63,10 @@ completeness.
 
 {{% rver-fragment name="v3-auth-rules" %}}
 
+#### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ### Canonical JSON
 
 {{% rver-fragment name="v1-canonical-json" %}}

content/rooms/v5.md

@@ -43,6 +43,10 @@ completeness.
 
 {{% rver-fragment name="v3-auth-rules" %}}
 
+#### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ### Event format
 
 {{% rver-fragment name="v4-event-explainer" %}}

content/rooms/v6.md

@@ -39,6 +39,12 @@ in [room version 5](/rooms/v5).
 
 ### Authorization rules for events
 
+`m.room.redaction` events are not explicitly part of the auth rules.
+They are still subject to the minimum power level rules, but should always
+fall into "10. Otherwise, allow". Instead of being authorized at the time
+of receipt, they are authorized at a later stage: see the
+[Handling Redactions](#handling-redactions) section below for more information.
+
 {{% added-in this=true %}} Like redactions, all rules relating specifically
 to events of type `m.room.aliases` are removed. They must still pass
 authorization checks relating to state events.
@@ -180,27 +186,6 @@ The rules are as follows:
     6.  Otherwise, allow.
 10. Otherwise, allow.
 
-{{% boxes/note %}}
-
-`m.room.redaction` events are no longer explicitly part of the above rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow".
-
-Redactions should only be sent to clients once both the redaction and
-redacted event are received and validated by the server. If both events
-are valid and have been seen by the server, then the server applies the
-redaction if one of the following conditions is met:
-
-1. The power level of the redaction event's `sender` is greater than or
-   equal to the *redact level*.
-2. The domain of the redaction event's `sender` matches that of the
-   original event's `sender`.
-
-If the server would apply a redaction, the redaction event is also sent
-to clients. Otherwise, the server simply waits for a valid partner event
-to arrive where it can then re-check the above.
-{{% /boxes/note %}}
-
 {{% boxes/note %}}
 Some consequences of these rules:
 
@@ -212,6 +197,10 @@ Some consequences of these rules:
     user's power level.
 {{% /boxes/note %}}
 
+#### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ### Canonical JSON
 
 {{% rver-fragment name="v6-canonical-json" %}}
@@ -225,10 +214,6 @@ completeness.
 
 {{% rver-fragment name="v2-state-res" %}}
 
-### Authorization rules
-
-{{% rver-fragment name="v3-auth-rules" %}}
-
 ### Event format
 
 {{% rver-fragment name="v4-event-explainer" %}}

content/rooms/v7.md

@@ -44,6 +44,12 @@ not include an `event_id` over federation in the same respect, so does
 not need a signature from that server. The event must still be signed by
 the server denoted by the `sender`, however.
 
+`m.room.redaction` events are not explicitly part of the auth rules.
+They are still subject to the minimum power level rules, but should always
+fall into "10. Otherwise, allow". Instead of being authorized at the time
+of receipt, they are authorized at a later stage: see the
+[Handling Redactions](#handling-redactions) section below for more information.
+
 The types of state events that affect authorization are:
 
 -   `m.room.create`
@@ -172,27 +178,6 @@ The rules are as follows:
     6.  Otherwise, allow.
 10. Otherwise, allow.
 
-{{% boxes/note %}}
-
-`m.room.redaction` events are no longer explicitly part of the above rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow".
-
-Redactions should only be sent to clients once both the redaction and
-redacted event are received and validated by the server. If both events
-are valid and have been seen by the server, then the server applies the
-redaction if one of the following conditions is met:
-
-1. The power level of the redaction event's `sender` is greater than or
-   equal to the *redact level*.
-2. The domain of the redaction event's `sender` matches that of the
-   original event's `sender`.
-
-If the server would apply a redaction, the redaction event is also sent
-to clients. Otherwise, the server simply waits for a valid partner event
-to arrive where it can then re-check the above.
-{{% /boxes/note %}}
-
 {{% boxes/note %}}
 Some consequences of these rules:
 
@@ -204,6 +189,10 @@ Some consequences of these rules:
     user's power level.
 {{% /boxes/note %}}
 
+#### Handling redactions
+
+{{% rver-fragment name="v3-handling-redactions" %}}
+
 ## Unchanged from v6
 
 The following sections have not been modified since v6, but are included for