From c8ec0f2e7629845f8d4f360ce99d4cf153cc09a2 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Thu, 20 Mar 2025 12:13:27 -0600 Subject: [PATCH] MSC: Soft unfailure for self redactions --- proposals/4275-soft-unfail-redactions.md | 48 ++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 proposals/4275-soft-unfail-redactions.md diff --git a/proposals/4275-soft-unfail-redactions.md b/proposals/4275-soft-unfail-redactions.md new file mode 100644 index 000000000..3fc5c0060 --- /dev/null +++ b/proposals/4275-soft-unfail-redactions.md @@ -0,0 +1,48 @@ +# MSC4275: Soft unfailure for self redactions + +When a user is removed from a room, the server may issue several redactions to their messages to clean +up rooms. Users may also use similar functionality, if supported by their server, to remove their own +messages after being removed. + +These self redactions can end up being [soft failed](https://spec.matrix.org/v1.13/server-server-api/#soft-failure) +due to the authorization rules preventing the redaction event from being validated, despite being part of the +DAG at a legal point. + +This proposal suggests that servers be less strict about soft failing self-redactions in particular. + +## Proposal + +When evaluating for soft failure, servers SHOULD permit `m.room.redaction` events which target events +by the same `sender` to go through normally, avoiding soft failure. Servers MAY impose limits on how +many events can bypass soft failure. Limits similar to the following may be of interest to developers: + +* Only the first 300 redactions from the same `sender` bypass soft failure. +* Only the first redaction targeting a given event bypasses soft failure. "Duplicate" redactions are + subject to soft failure. +* Only the redactions received within 1 hour of the most recent membership event change can bypass + soft failure. + +Applying some or all of the conditions may help servers avoid event spam abuse from making it to +local users over `/sync`. + +## Potential issues + +This may allow banned users to spam rooms with redaction events - the limits proposed above are potential +ways to mitigate the issue. + +## Alternatives + +Another approach could be to modify auth rules to exempt same-sender `m.room.redaction` events from the requirement +to pass authorization at the current resolved state. This approach may not work well with [how redactions work](https://spec.matrix.org/v1.13/rooms/v11/#handling-redactions). + +## Security considerations + +See Potential Issues. + +## Unstable prefix + +Not applicable. + +## Dependencies + +This proposal has no direct dependencies.