-
Notifications
You must be signed in to change notification settings - Fork 411
MSC4343: Making mass redactions use a new event type #4343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
|
@@ -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 | ||
|
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation requirements: