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.
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 are to 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 any more in the Matrix protocol, so there is no reason for them to be special-cased in this way.
The following are to be added to the list of subkeys of the content property which are preserved:
-
m.room.create
preserves all content. Rationale: the values in acreate
event are deliberately intended to last the lifetime of the room, and if values are redacted, there is no way to add correct settings afterwards. It therefore seems non-sensical to allow redaction of acreate
event. -
m.room.redaction
should allow theredacts
key (assuming MSC2174 is merged). Rationale: currently, redacting a redaction can lead to inconsistent results among homservers, depending on whether they receive them.room.redaction
result before or after it is redacted (and therefore may or may not redact the original event). -
m.room.power_levels
should allow (in addition to the keys already listed in the spec):- the
invite
key. Rationale: this is required to authenticatem.room.member
events with theinvite
membership. Currently, redacting apower_levels
event will mean that such events cannot be authenticated, potentially leading to a split-brain room.
- the
Currently it is not proposed to add these to the list of properties which are proposed for a redaction:
-
The
notifications
key ofm.room.power_levels
. Unlike the other properties inpower_levels
,notifications
does not play a part in authorising the events in the room graph. Once thepower_levels
are replaced, historical values of thenotifications
property are irrelevant. There is therefore no need for it to be protected from redactions. -
The
algorithm
key ofm.room.encryption
. Again, historical values ofm.room.encryption
have no effect, and servers do not use the value of the property to authenticate events.The effect of redacting an
m.room.encryption
event is much the same as that of sending a newm.room.encryption
event with noalgorithm
key. It's unlikely to be what was intended, but adding rules to the redaction algorithm will not help this.
The approach taken here has been to minimise the list of properties preserved by redaction; in general, the list is limited to those which are required by servers to authenticate events in the room. One reason for this is to simplify the implementation of servers and clients, but a more important philosophical reason is as follows.
Changing the redaction algorithm requires changes to both servers and clients, so changes are difficult and will happen rarely. Adding additional keys now sets an awkward precedent.
It is likely that in the future more properties will be defined which might be convenient to preserve under redaction. One of the two scenarios would then happen:
-
We would be forced to issue yet more updates to the redaction algorithm, with a new room versions and mandatory updates to all servers and clients, or:
-
We would end up with an awkward asymmetry between properties which were preserved under this MSC, and those which were introduced later so were not preserved.
In short, I consider it important for the elegance of the Matrix protocol that we do not add unnecessary properties to the list of those to be preserved by redaction.
Implementations should use org.matrix.msc2176
for the room version containing
this change until assigned to a specified room version. That room version should
use room version 6 as a base.