MSC4194: Batch redaction of events by sender within a room (including soft failed events) #4194
Conversation
special thanks to @tulir for prior discussion and inspiration from maunium/meowlnir@2d5eb93...de2aeda.
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server implementing the endpoint
- Client or bot using the endpoint
|
|
||
| `limit`: `integer` - The maximum number of events to redact. Default: 25. | ||
|
|
||
| #### Response |
There was a problem hiding this comment.
Should there be a communication of which Events failed to redact? For example due to a db failure. Similar to how s-s api handles failed events where you get a list of Event ids back. Or should the server retry forever to redact the event?
There was a problem hiding this comment.
I don't think it should ever fail to redact individual events 🤔
If the database explodes halfway through, that's the server's problem, it can throw an error on the entire request (but really the server should tell the database to not explode)
|
|
||
| ### Use case for self redaction | ||
|
|
||
| Implementers should be cautious over the use of this API for self |
There was a problem hiding this comment.
How about limiting self redaction to non dag critical Events? So messages and custom state events but not for example powerlevel Events or similar.
There was a problem hiding this comment.
DAG critical events are supposed to be redaction exempt already for critical fields i thought.
proposals/4194-user-redaction.md
Outdated
| { | ||
| "is_more_events": false, | ||
| "redacted_events": 5, | ||
| "soft_failed_events": 1 | ||
| } |
There was a problem hiding this comment.
I'd like some thoughts on the names of these fields. I'd also like to know if people agree that it makes less sense to return say an array of event_ids
There was a problem hiding this comment.
I'd like some thoughts on the names of these fields.
This is always going to be subjective but here goes:
soft_failed_eventsmight be slightly ambiguous in that it doesn't explicitly express that these events have also been redacted. Maybe the counters could be nested under a redactedkey?
"redacted": {
"total": 5,
"soft_failed": 1
}I'd also like to know if people agree that it makes less sense to return say an array of event_ids
IIUC the main use case for this API is to redact all of a user's events. The counters in the response could nicely be used to display progress. It might be nice to also return the total number of events to let clients display a completion percentage. Not sure if that's easy to get though?
I can't really think of a reason why the caller would need event IDs for the redacted events.
There was a problem hiding this comment.
Maybe the counters could be nested under a redactedkey?
Yeah that sounds like a good idea, 8f1900a
There was a problem hiding this comment.
I can't really think of a reason why the caller would need event IDs for the redacted events.
Yeah, i'll leave this open for now just in case someone else has thoughts
| ### 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. |
There was a problem hiding this comment.
Server implementers: Am I right in making a judgement call that this would be too complicated for the proposal?
There was a problem hiding this comment.
Meowlnir just has a hacky feature where if the last redacted event is <5 minutes old, it'll sleep for a bit and refetch events to redact. The assumption is that the most common soft fail issue is where events race with the ban, which should be covered by waiting a while for the ban to propagate.
A slightly less hacky method might be some way to opt into receiving soft-failed events, but that's probably a different MSC
There was a problem hiding this comment.
Yeah, Draupnir could in theory just call the endpoint again after a few minutes. I'd still like to just be able to give a flag to this endpoint, even if servers will only honor it for the next 10minutes or something.
Gnuxie
changed the title
|
@anoadragon453 informed me that Synapse coincidentally just merged an admin API with basically the exact same goal as this MSC: element-hq/synapse#17506 edit: by "exact same goal" I mean the functionality is the same and the code can hopefully be reused, not that it's a replacement for this MSC |
|
@tulir it's not the exact same goal as this MSC, this MSC is explicitly supposed to be used by room moderators who may not be synapse or server admins. |
|
There are several other servers than Synapse that also need effective moderation tooling, and I know Conduwuit would be eager to implement this MSC if it helps improve the overall moderation experience, especially increasing compatibility with moderation tooling. |
|
I think the fact that synapse made an admin API for this shows there's a need for it, so standardising it is a good idea, not that it makes this redundant. |
Rendered
special thanks to @tulir for discussing this with me and providing inspiration with meowlnir.
Signed-off-by: Gnuxie Gnuxie@protonmail.com