Merge pull request #2244 from tulir/mass_redactions

MSC2244: Mass redactions

Author: turt2live

proposals/2244-mass-redactions.md

@@ -0,0 +1,78 @@
+# Mass redactions
+Matrix, like any platform with public chat rooms, has spammers. Currently,
+redacting spam essentially requires spamming redaction events in a 1:1 ratio,
+which is not optimal<sup>[1](images/2244-redaction-spam.png)</sup>. Most
+clients do not even have any mass redaction tools, likely in part due to the
+lack of a mass redaction API. A mass redaction API on the other hand has not
+been implemented as it would require sending lots of events at once. However,
+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.
+
+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.
+
+### 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
+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.
+
+Like MSC2174, for improved compatibility with *newer* clients, servers should
+add a `redacts` array to the `content` of `m.room.redaction` events in *older*
+room versions when serving such events over the Client-Server API.
+
+### Number of redactions
+Room v4+ event IDs are 44 bytes long, which means the federation event size
+limit would cap a single redaction event at a bit less than 1500 targets.
+Redactions are not intrinsically heavy, so a separate limit should not be
+necessary.
+
+Due to the possible large number of redaction targets per redaction event,
+servers should omit the list of redaction targets from the `unsigned` ->
+`redacted_because` field of redacted events. If clients want to get the list
+of targets of a redaction event in `redacted_because`, they should read the
+`event_id` field of the `redacted_because` event and use the
+`/rooms/{roomId}/event/{eventId}` endpoint to fetch the content.
+
+### Client behavior
+Clients shall apply existing `m.room.redaction` target behavior over an array
+of event ID strings.
+
+### 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
+unchanged.
+
+After a server accepts an `m.room.redaction` 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
+  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
+authorized.
+
+> Servers should not send belated target events to clients if their redaction
+  was found to be in effect, as clients were not made aware of the redaction.
+  That fact is also used to simply ignore unauthorized targets and send the
+  events to clients normally.
+
+## Tradeoffs
+
+## Potential issues
+
+## Security considerations
+Server implementations should ensure that large redaction events do not become
+a DoS vector, e.g. by processing redactions in the background.