Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 17 additions & 13 deletions proposals/2244-mass-redactions.md
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

  • Like MSC4084, an unstable implementation in a new room version

Original file line number Diff line number Diff line change
Expand Up @@ -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.
Comment on lines +26 to 29
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to add up - if there's a new event type then the redacting client won't even send an m.room.redaction event. Unless the homeserver is to synthesise an m.room.redaction event, there's nowhere to add the redacts string; and if it's to synthesise the event, it should be spelled out here.

Expand All @@ -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
Expand Down
63 changes: 63 additions & 0 deletions proposals/4343-modify-msc2244-use-new-event-type.md
Original file line number Diff line number Diff line change
@@ -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.