MSC: Soft unfailure for self redactions

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.