From ff4c626cc3beebccd9c8893e00b472a4602b8a3b Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 15:40:10 +0100 Subject: [PATCH 01/23] User Redaction draft special thanks to @tulir for prior discussion and inspiration from https://github.com/maunium/meowlnir/compare/2d5eb93e55d8...de2aeda5f3cf. --- proposals/0000-user-redaction.md | 138 +++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 proposals/0000-user-redaction.md diff --git a/proposals/0000-user-redaction.md b/proposals/0000-user-redaction.md new file mode 100644 index 00000000000..ae8308aa066 --- /dev/null +++ b/proposals/0000-user-redaction.md @@ -0,0 +1,138 @@ +# MSC0000: User redaction + +Targeted attacks are a problem in Matrix. Typically throwaway users +are used to target matrix rooms with abuse in the form of multiple +messages. The intent of the spammer is to fill the room timeline view +in clients with abuse. + +Typically, a moderator will be pinged by a bystander, and the +moderator will respond by first banning the throwaway account and then +issuing redactions for each event the throwaway account sent in their +client. + +Due to the architecture of various Matrix APIs, there are multiple +issues that can occur in the moderator's flow. + +1. Calling `/messages` is required for some clients to accurately get + the full list of `event_ids` the throwaway account sent. This is a + compounding problem because homeservers can be slow to respond to a + filtered `/messages` request and then the client must still process + the response and issue a redaction for each event returned. + This is how both Mjolnir and Draupnir source events for redaction. + +2. The client must call `/rooms/redact/event` for each target event, + requiring the client to make multiple requests, further impeding + response time. Homeservers typically rate limit the number of + redactions that a client can send to `/redact` evenly with `/send`, + which further compounds response time. + [MSC2244](https://github.com/matrix-org/matrix-spec-proposals/pull/2244) + tried to alleviate part of the problem by allowing the redactions + to be sent in one event. But there currently are no endpoints that + allow you to create this event[^create-mass-redaction]. + +3. Soft failure of events sent by the throwaway account after a ban + stop them from being visible to the matrix client, and there is no + way for a moderator to redact them. This is a huge problem that + occurs far more frequently than it should. + +[^create-mass-redaction]: I think? +## Proposal + +This proposal introduces a very simple client-server endpoint to +alleviate all three of the concerns surrounding the moderators +redaction flow. + +### Redacting a users's events + +A new endpoint is introduced into the client-server spec. + +`POST /_matrix/client/v1/rooms/{roomID}/redact/user/{userID}` + +This endpoint redacts the target matrix user's unredacted events in +reverse chronological order, starting from the most +chronologically-recent visible event in the room history for the +requesting user. + +This endpoint is blind to the distinction between normal and +soft-failed events, and will cause redactions to be issued +for any soft-failed events that match the scope of the +request. + +It is left to an implementation detail whether a `m.room.redaction` +event is created for each event, or +[MSC2244](https://github.com/matrix-org/matrix-spec-proposals/pull/2244) +is employed. We expect that for now, most implementations will +issue one `m.room.redaction` event for each event under +the scope of the request. + +#### Rate limiting + +This API SHOULD be rate limited, but the number `m.room.redaction` +events emitted SHOULD NOT be the subject of the rate limit. +But instead the number of events that have been redacted overall. +This is to cover semantics of MSC2244. +Servers SHOULD be more liberal in the number of events that +can be redacted in comparison to rate limits for `/send` when +the endpoint is being used to redact another user's events. +Rather than their own events. + +#### Query parameters + +`limit`: `integer` - The maximum number of events to redact. Default: 25. + +#### Respone + +`is_more_events`: `boolean` - Whether there are more events outside of +the scope of the request sent by the user that could be redacted, but +have not been because of the `limit` query parameter. If +`_is_more_events` is true, then the server should expect that the +client can optionally be called again, to redact more even more events. + +`redacted_events`: `integer` - The number of events that have been redacted, including soft failed events. + +`soft_failed_events`: `integer` - The number of soft failed events that have been redacted. + +``` +200 OK +Content-Type: application/json + +{ + "is_more_events": false, + "redacted_events": 5 + "soft_failed_events": 1 +} +``` + +##### Limited response + +Servers may wish to limit the maximum size of the limit that can be specified. + +``` +{ + "errcode": "M_LIMIT_TOO_LARGE", + "error": "The limit parameter specified for this request is too large.", + "max_limit": 100 +} +``` + +## Potential issues + +None so far. + +## Alternatives + + +## Security considerations + +### Use case for self redaction + +Implementors should be cautious over the use of this API for self +redaction. We might omit that use case from the MSC if there are concerns. + +## Unstable prefix + +Uhm help? + +## Dependencies + +None From 9734b959803535fd1133d00e8d071b337fd7453b Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 15:45:54 +0100 Subject: [PATCH 02/23] match MSC number. --- proposals/{0000-user-redaction.md => 4194-user-redaction.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{0000-user-redaction.md => 4194-user-redaction.md} (99%) diff --git a/proposals/0000-user-redaction.md b/proposals/4194-user-redaction.md similarity index 99% rename from proposals/0000-user-redaction.md rename to proposals/4194-user-redaction.md index ae8308aa066..9d1489880ba 100644 --- a/proposals/0000-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -1,4 +1,4 @@ -# MSC0000: User redaction +# MSC4194: User redaction Targeted attacks are a problem in Matrix. Typically throwaway users are used to target matrix rooms with abuse in the form of multiple From 0405c626972cd870efa7a3ce50eabda9ba5c8c89 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 15:49:47 +0100 Subject: [PATCH 03/23] spelling. --- proposals/4194-user-redaction.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 9d1489880ba..93034fccd6a 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -42,7 +42,7 @@ This proposal introduces a very simple client-server endpoint to alleviate all three of the concerns surrounding the moderators redaction flow. -### Redacting a users's events +### Redacting a user's events A new endpoint is introduced into the client-server spec. @@ -80,7 +80,7 @@ Rather than their own events. `limit`: `integer` - The maximum number of events to redact. Default: 25. -#### Respone +#### Response `is_more_events`: `boolean` - Whether there are more events outside of the scope of the request sent by the user that could be redacted, but @@ -126,7 +126,7 @@ None so far. ### Use case for self redaction -Implementors should be cautious over the use of this API for self +Implementers should be cautious over the use of this API for self redaction. We might omit that use case from the MSC if there are concerns. ## Unstable prefix From ba6340dc46e2a7a8fce76d7af40b1735b0b2c69a Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 15:55:31 +0100 Subject: [PATCH 04/23] consistency in langauge. --- proposals/4194-user-redaction.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 93034fccd6a..452374177fb 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -7,14 +7,14 @@ in clients with abuse. Typically, a moderator will be pinged by a bystander, and the moderator will respond by first banning the throwaway account and then -issuing redactions for each event the throwaway account sent in their -client. +issuing redactions via a client for each event the throwaway account +sent. Due to the architecture of various Matrix APIs, there are multiple issues that can occur in the moderator's flow. 1. Calling `/messages` is required for some clients to accurately get - the full list of `event_ids` the throwaway account sent. This is a + the full list of `event_id`s the throwaway account sent. This is a compounding problem because homeservers can be slow to respond to a filtered `/messages` request and then the client must still process the response and issue a redaction for each event returned. @@ -67,7 +67,7 @@ the scope of the request. #### Rate limiting -This API SHOULD be rate limited, but the number `m.room.redaction` +This endpoint SHOULD be rate limited, but the number `m.room.redaction` events emitted SHOULD NOT be the subject of the rate limit. But instead the number of events that have been redacted overall. This is to cover semantics of MSC2244. @@ -85,7 +85,7 @@ Rather than their own events. `is_more_events`: `boolean` - Whether there are more events outside of the scope of the request sent by the user that could be redacted, but have not been because of the `limit` query parameter. If -`_is_more_events` is true, then the server should expect that the +`is_more_events` is true, then the server should expect that the client can optionally be called again, to redact more even more events. `redacted_events`: `integer` - The number of events that have been redacted, including soft failed events. From 9a0bc266427b5f483499ed8f34009b5b5d342e8d Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 15:58:39 +0100 Subject: [PATCH 05/23] unstable prefix. --- proposals/4194-user-redaction.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 452374177fb..35dc4cee118 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -131,7 +131,10 @@ redaction. We might omit that use case from the MSC if there are concerns. ## Unstable prefix -Uhm help? +If nothing exists for what `M_LIMIT_TOO_LARGE` is trying to do, then +`org.matrix.msc4194.LIMIT_TOO_LARGE` + +`POST /_matrix/client/unstable/org.matrix.msc4194/rooms/{roomID}/redact/user/{userID}` ## Dependencies From 8af0181b8a7325d35024165a58d1357a1f4ca5c8 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 16:00:37 +0100 Subject: [PATCH 06/23] alternatives --- proposals/4194-user-redaction.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 35dc4cee118..3c2e1189ccf 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -121,6 +121,9 @@ None so far. ## Alternatives +* An endpoint could be developed to expose soft-failed events to + clients or appservices such as in + [MSC4109](https://github.com/matrix-org/matrix-spec-proposals/pull/4109). ## Security considerations From 1331f86f4a57226dc5bffc00fed6cf698047454a Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 16:03:59 +0100 Subject: [PATCH 07/23] explicit about what happens to known redacted events --- proposals/4194-user-redaction.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 3c2e1189ccf..9cb55646f78 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -58,6 +58,9 @@ soft-failed events, and will cause redactions to be issued for any soft-failed events that match the scope of the request. +Events known to have already been redacted SHOULD be ignored and MUST +NOT contribute to the request limit. + It is left to an implementation detail whether a `m.room.redaction` event is created for each event, or [MSC2244](https://github.com/matrix-org/matrix-spec-proposals/pull/2244) From 35d7afff63957491bb277c543c7e84af20baf142 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 16:06:53 +0100 Subject: [PATCH 08/23] feedback from @tulir. --- proposals/4194-user-redaction.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 9cb55646f78..0f32a947dc6 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -138,9 +138,15 @@ redaction. We might omit that use case from the MSC if there are concerns. ## Unstable prefix If nothing exists for what `M_LIMIT_TOO_LARGE` is trying to do, then -`org.matrix.msc4194.LIMIT_TOO_LARGE` - -`POST /_matrix/client/unstable/org.matrix.msc4194/rooms/{roomID}/redact/user/{userID}` +`org.matrix.msc4194.LIMIT_TOO_LARGE`. + +Until the MSC is accepted, implementations can use `org.matrix.msc4194` as the +unstable prefix and as a flag in the `unstable_features` section of `/versions`: +* `/_matrix/client/unstable/org.matrix.msc4194/rooms/{roomID}/redact/user/{userID}` + instead of `/_matrix/client/v1/rooms/{roomID}/redact/user/{userID}` +Once the MSC is merged, the `org.matrix.msc4194.stable` unstable feature flag +can be used to advertise support for the stable version of the endpoint, until +the spec release with the endpoint is advertised. ## Dependencies From f6f944002998316d0807a6f1d303a698f07890df Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 16:17:39 +0100 Subject: [PATCH 09/23] ammend limited response to be simpler. --- proposals/4194-user-redaction.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 0f32a947dc6..297e1f632ba 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -106,15 +106,24 @@ Content-Type: application/json } ``` -##### Limited response +#### Limited response -Servers may wish to limit the maximum size of the limit that can be specified. +Servers may wish to limit the maximum size of the limit that can be +specified. This maximum limit may even be dynamic to comply with rate +limiting. + +To do this, they should simply redact less events than the limit provided +by the client. ``` +POST /.../?limit=1000 +200 OK +Content-Type: application/json + { - "errcode": "M_LIMIT_TOO_LARGE", - "error": "The limit parameter specified for this request is too large.", - "max_limit": 100 + "is_more_events": true, + "redacted_events": 25, + "soft_failed_events": 3 } ``` @@ -137,9 +146,6 @@ redaction. We might omit that use case from the MSC if there are concerns. ## Unstable prefix -If nothing exists for what `M_LIMIT_TOO_LARGE` is trying to do, then -`org.matrix.msc4194.LIMIT_TOO_LARGE`. - Until the MSC is accepted, implementations can use `org.matrix.msc4194` as the unstable prefix and as a flag in the `unstable_features` section of `/versions`: * `/_matrix/client/unstable/org.matrix.msc4194/rooms/{roomID}/redact/user/{userID}` From 003f53b7cea4f8664a137b4220bd46d2c5fe184c Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 16:24:52 +0100 Subject: [PATCH 10/23] clarity about soft failure. --- proposals/4194-user-redaction.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 297e1f632ba..79b74b162a6 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -30,12 +30,15 @@ issues that can occur in the moderator's flow. to be sent in one event. But there currently are no endpoints that allow you to create this event[^create-mass-redaction]. -3. Soft failure of events sent by the throwaway account after a ban - stop them from being visible to the matrix client, and there is no - way for a moderator to redact them. This is a huge problem that - occurs far more frequently than it should. +3. Soft failure of events sent by the throwaway account after the + moderator bans the throwaway. These events are not visible to the + moderator's matrix client, and there is no way for a moderator to + redact these events. This is a huge problem that occurs far more + frequently than it should[^often-soft-failure]. [^create-mass-redaction]: I think? + +[^often-soft-failure] https://github.com/matrix-org/synapse/issues/9329 ## Proposal This proposal introduces a very simple client-server endpoint to From 7d71fcb744efc3b7aef11d73265e6e128678d05a Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 16:26:07 +0100 Subject: [PATCH 11/23] broked footnote oopsie. --- proposals/4194-user-redaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 79b74b162a6..7434dfc7ff7 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -38,7 +38,7 @@ issues that can occur in the moderator's flow. [^create-mass-redaction]: I think? -[^often-soft-failure] https://github.com/matrix-org/synapse/issues/9329 +[^often-soft-failure]: https://github.com/matrix-org/synapse/issues/9329 ## Proposal This proposal introduces a very simple client-server endpoint to From 356cc0b32e79c2d4a50ba464b47345e29c66b839 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 17:46:00 +0100 Subject: [PATCH 12/23] more explicit note about limit semantics --- proposals/4194-user-redaction.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 7434dfc7ff7..465be8b12f0 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -84,7 +84,12 @@ Rather than their own events. #### Query parameters -`limit`: `integer` - The maximum number of events to redact. Default: 25. +`limit`: `integer` - The maximum number of events to +redact. Default: 25. + +Client authors should be aware that the server may return less than +the `limit` even when `is_more_events` is `true`, and so should always +check the response. #### Response From 8d0224e53bbcf705529d3c43267d0aba856ed580 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 17:55:59 +0100 Subject: [PATCH 13/23] forward compatibility note. --- proposals/4194-user-redaction.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 465be8b12f0..f151defbba9 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -137,7 +137,12 @@ Content-Type: application/json ## Potential issues -None so far. +### Forward compatibility with `/messages` style query parameters + +We probably want to keep the endpoint compatible with `/messages` +style query pamarameters if the endpoint needs to be extended in the +future. It is our current assessment that we are currently forward +compatible. But someone should double check. ## Alternatives From 7c1e511008b0f10f4c6feeef7a20e6b621ffb0e2 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 18:06:05 +0100 Subject: [PATCH 14/23] minor typos --- proposals/4194-user-redaction.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index f151defbba9..38b9bfe8480 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -97,7 +97,7 @@ check the response. the scope of the request sent by the user that could be redacted, but have not been because of the `limit` query parameter. If `is_more_events` is true, then the server should expect that the -client can optionally be called again, to redact more even more events. +client can optionally be called again, to redact even more events. `redacted_events`: `integer` - The number of events that have been redacted, including soft failed events. @@ -109,7 +109,7 @@ Content-Type: application/json { "is_more_events": false, - "redacted_events": 5 + "redacted_events": 5, "soft_failed_events": 1 } ``` From b424f21733707b8022856ebc26fa57a484bd3bc9 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 18:07:23 +0100 Subject: [PATCH 15/23] oopsie typos --- proposals/4194-user-redaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 38b9bfe8480..e7a98a39b58 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -97,7 +97,7 @@ check the response. the scope of the request sent by the user that could be redacted, but have not been because of the `limit` query parameter. If `is_more_events` is true, then the server should expect that the -client can optionally be called again, to redact even more events. +client can optionally call the endpoint again, to redact even more events. `redacted_events`: `integer` - The number of events that have been redacted, including soft failed events. From 4927088fa36df2395028fec95436881d13d7eaa3 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 18:24:49 +0100 Subject: [PATCH 16/23] a note about intent of the API with regards to it being a batch op. --- proposals/4194-user-redaction.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index e7a98a39b58..cd1ac39920c 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -71,16 +71,23 @@ is employed. We expect that for now, most implementations will issue one `m.room.redaction` event for each event under the scope of the request. +The action of redacting the events that are determined to be within +the scope of the request should be seen as an atomic operation from +the perspective of the client, regardless of whether multiple +`m.room.redaction` events are issued by the server. + #### Rate limiting This endpoint SHOULD be rate limited, but the number `m.room.redaction` events emitted SHOULD NOT be the subject of the rate limit. But instead the number of events that have been redacted overall. This is to cover semantics of MSC2244. + Servers SHOULD be more liberal in the number of events that can be redacted in comparison to rate limits for `/send` when the endpoint is being used to redact another user's events. -Rather than their own events. +Rather than their own events. The intent of being liberal +is to allow moderators to remove spam faster. #### Query parameters From e204eaac6293efa076b62fade651bc35b072c0d4 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Sun, 15 Sep 2024 20:22:26 +0100 Subject: [PATCH 17/23] consideration about redacting future soft-failed events. --- proposals/4194-user-redaction.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index cd1ac39920c..209a4a1c505 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -151,6 +151,25 @@ style query pamarameters if the endpoint needs to be extended in the future. It is our current assessment that we are currently forward compatible. But someone should double check. +### Redacting "future" soft-failed events + +Given that a request to the `/rooms/redact/user` endpoint is very +likely to occur after a room ban, then it makes sense that there could +still be soft failed events outside the scope of the request. The +moderator's homeserver is likely to discover soft-failed events from +the target user after the moderator's request has completed. + +It could make sense to add a flag to the endpoint to tell the +moderator's homeserver to issue redactions on their behalf for the +newly discovered events. However, this could be complicated for +servers to implement. The flag would have to reset if the target user +is unbanned, and all incoming soft failed events will have to be +checked against a list of flagged servers. + +At the moment we will remain forward compatible with a future +proposal to add a flag. + + ## Alternatives * An endpoint could be developed to expose soft-failed events to From 8f1900a4b92db5735657311ae123c79cc649e43a Mon Sep 17 00:00:00 2001 From: gnuxie Date: Tue, 17 Sep 2024 21:23:38 +0100 Subject: [PATCH 18/23] Improve naming of response fields. --- proposals/4194-user-redaction.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 209a4a1c505..2ee5ba5f663 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -106,9 +106,13 @@ have not been because of the `limit` query parameter. If `is_more_events` is true, then the server should expect that the client can optionally call the endpoint again, to redact even more events. -`redacted_events`: `integer` - The number of events that have been redacted, including soft failed events. +`redacted_events`: `object` - An object with the following fields: -`soft_failed_events`: `integer` - The number of soft failed events that have been redacted. +* `total`: `integer` - The number of events that have been redacted, + including soft failed events. + +* `soft_failed`: `integer` - The number of soft failed events that + have been redacted. ``` 200 OK @@ -116,8 +120,10 @@ Content-Type: application/json { "is_more_events": false, - "redacted_events": 5, - "soft_failed_events": 1 + "redacted_events": { + "total": 5, + "soft_failed": 1 + } } ``` @@ -137,8 +143,10 @@ Content-Type: application/json { "is_more_events": true, - "redacted_events": 25, - "soft_failed_events": 3 + "redacted_events": { + "total": 25, + "soft_failed": 3 + } } ``` From 8f238c708bda49f050777f718de8e45983adba55 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 18 Sep 2024 13:19:56 +0100 Subject: [PATCH 19/23] Make it clearer who the sender of redaction events is. --- proposals/4194-user-redaction.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 2ee5ba5f663..e299b7cdc7c 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -51,10 +51,13 @@ A new endpoint is introduced into the client-server spec. `POST /_matrix/client/v1/rooms/{roomID}/redact/user/{userID}` -This endpoint redacts the target matrix user's unredacted events in -reverse chronological order, starting from the most -chronologically-recent visible event in the room history for the -requesting user. +This endpoint redacts the target matrix user's unredacted events by +sending redactions on behalf of the requesting user. + +The target user's unredacted events are sourced in reverse +chronological order, starting from the most chronologically-recent +visible event in the room history for the requesting user. +Similarly to `/rooms/{roomID}/messages?dir=b`. This endpoint is blind to the distinction between normal and soft-failed events, and will cause redactions to be issued @@ -69,7 +72,7 @@ event is created for each event, or [MSC2244](https://github.com/matrix-org/matrix-spec-proposals/pull/2244) is employed. We expect that for now, most implementations will issue one `m.room.redaction` event for each event under -the scope of the request. +the scope of the request. Sent by the requesting user. The action of redacting the events that are determined to be within the scope of the request should be seen as an atomic operation from @@ -89,6 +92,12 @@ the endpoint is being used to redact another user's events. Rather than their own events. The intent of being liberal is to allow moderators to remove spam faster. +#### Path parameters + +`roomID`: `string` - The room to get events to redact from. + +`userID`: `string` - The sender of the events to redact. + #### Query parameters `limit`: `integer` - The maximum number of events to From f01e5a625c573fb00725c36d3a047f1375c60588 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 18 Sep 2024 13:32:22 +0100 Subject: [PATCH 20/23] Make it clear that this is not an admin API of some kind. --- proposals/4194-user-redaction.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index e299b7cdc7c..14c37c19f50 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -48,6 +48,10 @@ redaction flow. ### Redacting a user's events A new endpoint is introduced into the client-server spec. +The endpoint is introduced with the intention to allow convenient and +quick bulk redaction of spam events for room moderators. Who may not +necessarily have administrative privileges on their homeserver, and +will also need to redact messages from remote users. `POST /_matrix/client/v1/rooms/{roomID}/redact/user/{userID}` @@ -74,11 +78,6 @@ is employed. We expect that for now, most implementations will issue one `m.room.redaction` event for each event under the scope of the request. Sent by the requesting user. -The action of redacting the events that are determined to be within -the scope of the request should be seen as an atomic operation from -the perspective of the client, regardless of whether multiple -`m.room.redaction` events are issued by the server. - #### Rate limiting This endpoint SHOULD be rate limited, but the number `m.room.redaction` From cd5303f02e622496da2da4ee028c6d762e773395 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 18 Sep 2024 13:32:42 +0100 Subject: [PATCH 21/23] make it clear why i want concession on rate limits --- proposals/4194-user-redaction.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 14c37c19f50..313850e6e2a 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -85,11 +85,12 @@ events emitted SHOULD NOT be the subject of the rate limit. But instead the number of events that have been redacted overall. This is to cover semantics of MSC2244. -Servers SHOULD be more liberal in the number of events that -can be redacted in comparison to rate limits for `/send` when -the endpoint is being used to redact another user's events. -Rather than their own events. The intent of being liberal -is to allow moderators to remove spam faster. +Servers SHOULD be more liberal in the number of events that can be +redacted in comparison to rate limits for `/send` when the endpoint is +being used to redact another user's events. Rather than the +requester's own events. The intent of being liberal is to allow +moderators to remove spam quickly, rather than struggling behind rate +limits for `/rooms/redact/event` or `/send`. #### Path parameters From cb55d016ec36f4ccb207a5eea78e2916f0e36581 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 18 Sep 2024 20:09:12 +0100 Subject: [PATCH 22/23] Change MSC name so its more obvious what it is at a glance. --- proposals/4194-user-redaction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index 313850e6e2a..b6232dbd6fc 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -1,4 +1,4 @@ -# MSC4194: User redaction +# MSC4194: Batch redaction of events by sender within a room (including soft failed events) Targeted attacks are a problem in Matrix. Typically throwaway users are used to target matrix rooms with abuse in the form of multiple From ee4bc78c989f226786df2b9d58ec3ca5e87a9887 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 29 Jan 2025 23:43:41 +0000 Subject: [PATCH 23/23] Add reason to request body. https://github.com/matrix-org/matrix-spec-proposals/pull/4194#discussion_r1934551302 --- proposals/4194-user-redaction.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proposals/4194-user-redaction.md b/proposals/4194-user-redaction.md index b6232dbd6fc..48268aebf63 100644 --- a/proposals/4194-user-redaction.md +++ b/proposals/4194-user-redaction.md @@ -107,6 +107,11 @@ Client authors should be aware that the server may return less than the `limit` even when `is_more_events` is `true`, and so should always check the response. +#### Request body + +`reason`: `string` - The reason for redacting the user's events +(Optional). + #### Response `is_more_events`: `boolean` - Whether there are more events outside of