diff --git a/proposals/2244-mass-redactions.md b/proposals/2244-mass-redactions.md index 4f410356f61..746b360f627 100644 --- a/proposals/2244-mass-redactions.md +++ b/proposals/2244-mass-redactions.md @@ -9,17 +9,21 @@ this problem could be solved by allowing a single redaction event to redact many events instead of sending many redaction events. ## Proposal -This proposal builds upon [MSC2174](https://github.com/matrix-org/matrix-doc/pull/2174) -and suggests making the `redacts` field in the content of `m.room.redaction` -events an array of event ID strings instead of a single event ID string. +**Updated by [MSC4343](https://github.com/matrix-org/matrix-spec-proposals/pull/4343)**: +Instead of modifying `redacts` on `m.room.redaction`, this proposal now copies +`m.room.redaction` to `m.room.redactions` with the same `redacts` change. As such, +it is no longer built upon [MSC2174](https://github.com/matrix-org/matrix-doc/pull/2174). + +This proposal suggests copying the schema of `m.room.redaction` to a new event +type, `m.room.redactions`, with `redacts` being an array of event ID strings +instead of a single event ID string. It would be easiest to do this before MSC2174 is written into the spec, as then -only one migration would be needed: from an event-level redacts string to a -content-level redacts array. +only one migration would be needed instead of needing to introduce a new event +type: from an event-level redacts string to a content-level redacts array. ### Backwards compatibility -There is no easy way to stay fully compatible with *older* clients, so the -proposed solution is to not support them. In order to not break old clients +In order to not break old clients completely, servers should still add a `redacts` string containing one of the redacted event IDs to the top level of `m.room.redaction` events in *newer* room versions when serving such events over the Client-Server API. @@ -43,25 +47,25 @@ of targets of a redaction event in `redacted_because`, they should read the ### Client behavior Clients shall apply existing `m.room.redaction` target behavior over an array -of event ID strings. +of event ID strings in `m.room.redactions`. ### Server behavior (auth rules) -The target events of an `m.room.redaction` shall no longer be considered when -authorizing an `m.room.redaction` event. Any other existing rules remain +The target events of an `m.room.redactions` event shall no longer be considered when +authorizing an `m.room.redactions` event. Any other existing rules remain unchanged. -After a server accepts an `m.room.redaction` using the modified auth rules, it +After a server accepts an `m.room.redactions` using the modified auth rules, it evaluates individually whether each target can be redacted under the existing room v5 auth rules. Servers MUST NOT include failing and unknown entries to clients. > Servers do not know whether redaction targets are authorized at the time they - receive the `m.room.redaction` unless they are in possession of the target + receive the `m.room.redactions` unless they are in possession of the target event. Implementations retain entries in the original list which were not shared with clients to later evaluate the target's redaction status. When the implementation receives a belated target from an earlier -`m.room.redaction`, it evaluates at that point whether the redaction is +`m.room.redactions`, it evaluates at that point whether the redaction is authorized. > Servers should not send belated target events to clients if their redaction diff --git a/proposals/4343-modify-msc2244-use-new-event-type.md b/proposals/4343-modify-msc2244-use-new-event-type.md new file mode 100644 index 00000000000..94b51339c4e --- /dev/null +++ b/proposals/4343-modify-msc2244-use-new-event-type.md @@ -0,0 +1,63 @@ +# MSC4343: Making mass redactions use a new event type + +[MSC2244 (accepted)](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/2244-mass-redactions.md) +introduces a concept of "mass redactions", where a single `m.room.redaction` event can redact upwards +of about 1500 other events. This massively improves scalability of the redactions system in Matrix, +though by reusing `m.room.redaction` (and the `redacts`) key, the MSC becomes backwards incompatible +for clients which are expecting `redacts` to be a string. + +MSC2244 does call out that it should have landed prior to [MSC2174 (merged)](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/2174-move-redacts-key.md) +to minimize this breaking change, but unfortunately that did not happen in practice. + +This proposal suggests moving mass redactions to a new `m.room.redactions` (plural of `m.room.redaction`) +event type to minimize breakage in clients. + + +## Proposal + +Instead of modifying the existing `m.room.redaction` event schema, MSC2244 is updated to say it uses +a new event type: `m.room.redactions`. + +This change is primarily to maintain support for outdated clients (and to a degree, servers) which +may not support the `redacts` key being an array instead of string. + + +## Process note + +MSC2244 is accepted under an older MSC process and has no known implementations. Typically, changes +such as those described above would happen prior to acceptance as they would have been caught during +implementation. + +To honour the older MSC process as best as possible, MSC2244 is considered to remain accepted, but +is modified directly by this MSC as a pre-merge change. This MSC requires an implementation before +the modifications are accepted into the spec, and further MSC2244. This is why the PR for this MSC +modifies MSC2244 itself. + + +## Potential issues + +Using another event type for redactions isn't great. Ideally, there would be a non-conflicting key +or fallback we could provide to `redacts` which has the same meaning, however it's difficult to +represent an array as a single string target within the same event. + + +## Alternatives + +No significant alternatives. Proposals like [MSC4292](https://github.com/matrix-org/matrix-spec-proposals/pull/4292) +may prove valuable in gating MSC2244 behind a (breaking) room version, though such areas of thinking +are experimental as of writing. + + +## Security considerations + +No significant security concerns apply. + + +## Unstable prefix + +While this proposal is not considered stable, implementations should use `org.matrix.msc2244.redactions` +in place of `m.room.redactions`. Further, MSCs should note the room version requirements of MSC2244. + +## Dependencies + +This proposal has a mandatory dependency on MSC2244.