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>
1.1 KiB
| toc_hide |
|---|
| true |
{{% added-in this=true %}} In room versions 1 and 2, redactions were explicitly part of the authorization rules under Rule 11. As of room version 3, these conditions no longer exist as represented by this version's 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:
- The power level of the redaction event's
senderis greater than or equal to the redact level. - The domain of the redaction event's
sendermatches that of the original event'ssender.
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.