Proposal to allow multiple targets for one redaction event
Signed-off-by: Tulir Asokan <tulir@maunium.net>pull/2244/head
parent
8ca50eaf9f
commit
ec38013daa
@ -0,0 +1,66 @@
|
||||
# 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]</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] 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.
|
||||
|
||||
### 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.
|
||||
|
||||
### Auth rules
|
||||
The redaction auth rules should change to iterate the array and check if the
|
||||
sender has the privileges to redact each event.
|
||||
|
||||
There are at least two potential ways to handle targets that are not found or
|
||||
rejected: soft failing until all targets are found and handling each target
|
||||
separately.
|
||||
|
||||
#### Soft fail
|
||||
Soft fail the event until all targets are found, then accept only if the sender
|
||||
has the privileges to redact every listed event. This is how redactions
|
||||
currently work.
|
||||
|
||||
This has the downside of requiring servers to fetch all the target events (and
|
||||
possibly forward them to clients) before being able to process and forward the
|
||||
redaction event.
|
||||
|
||||
#### Handle each target separately
|
||||
Handle each target separately: if some targets are not found, remember the
|
||||
redaction and check auth rules when the target is received. This option brings
|
||||
some complexities, but might be more optimal in situations such as a spam
|
||||
attack.
|
||||
|
||||
When receiving a redaction event:
|
||||
* Ignore illegal targets
|
||||
* "Remember" targets that can't be found
|
||||
* Send legal target event IDs to clients in the redaction event.
|
||||
|
||||
When receiving an event that is "remembered" to be possibly redacted by an
|
||||
earlier redaction, check if the redaction was legal, and if it was, do not
|
||||
send the event to clients.
|
||||
|
||||
## Tradeoffs
|
||||
|
||||
## Potential issues
|
||||
|
||||
## Security considerations
|
||||
|
||||
|
||||
[1]: https://img.mau.lu/hEqqt.png
|
||||
[MSC2174]: https://github.com/matrix-org/matrix-doc/pull/2174
|
Loading…
Reference in New Issue