d4c74d37a9
* Update documentation style & fix room version heading order Also add a missing signing key section to v6. This additionally contains various edits to the fragments to have them make a little bit more sense in context. Finally, this updates various aspects of the documentation style which haven't previously been considered - they're added here considering we're in the area. * changelog * enhanced changelogs * Minor wording adjustments * Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
24 lines
1.1 KiB
Markdown
24 lines
1.1 KiB
Markdown
---
|
|
toc_hide: true
|
|
---
|
|
|
|
{{% added-in this=true %}} 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 [this version's authorization rules](#authorization-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.
|