matrix-spec/proposals/2176-update-redaction-rules.md

MSC2176: Update the redaction rules

The current redaction algorithm is now somewhat dated. This MSC proposes a number of changes to the rules which will improve the security and reliability of the Matrix protocol.

Proposal

The following changes will require a new room version, since changes to the redaction algorithm also change the way that event hashes (and hence event IDs) are calculated.

The following event keys should be removed from the list of those to be preserved by a redaction:

• membership
• prev_state

(Note this refers to the event-level membership property, rather than the similarly-named sub-property under the content key.)

Rationale: neither of the above properties have defined meanings in the Matrix protocol, so there is no reason for them to be special-cased in this way.

The following should be added to the list of subkeys of the content property which should be preserved:

• m.room.redaction should allow the redacts key (assuming MSC2174 is merged). Rationale: currently, redacting a redaction can lead to inconsistent results among homservers, depending on whether they receive the m.room.redaction result before or after it is redacted (and therefore may or may not redact the original event).

• m.room.create should allow the room_version key. Currently, redacting an m.room.create event will make the room revert to a v1 room.

• m.room.power_levels should allow:

  • the invite key. Rationale: this is required to authenticate m.room.member events with the invite membership. Currently, redacting a power_levels event will mean that such events cannot be authenticated, potentially leading to a split-brain room.

  • the notifications key. Rationale: symmetry with the other power_levels settings. (Maybe? See https://github.com/matrix-org/matrix-doc/issues/1601#issuecomment-511237744.)

Potential issues

What if there is spam in sub-properties of the notifications property of power-levels? Should we not be able to redact it?