MSC2815: Proposal to allow room moderators to view redacted event content #2815
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,51 @@ | ||
| # Proposal to allow room moderators to view redacted event content | ||
| ## Problem | ||
| Currently if a user deletes a message, most clients will immediately forget the | ||
| content and spec-compliant server implementations will stop serving the content | ||
| to anyone. This instant deletion means that users could potentially send | ||
| messages that aren't allowed, and redact them before a moderator sees them. | ||
|
|
||
| Most servers don't remove the content from the database immediately (e.g. | ||
| Synapse defaults to removing after 7 days), one reason being moderation of | ||
| content that the server admins don't want to allow. However, room moderators | ||
| don't have any way to access that content, unless they happen to have their own | ||
| server. | ||
|
|
||
| ## Proposal | ||
| The proposed solution is extending the `GET /rooms/{roomId}/event/{eventId}` | ||
| endpoint with a query parameter called `include_unredacted_content`. Clients | ||
| can request the server to include content even if the event has been redacted | ||
| by setting the parameter value to `true`. | ||
|
Comment on lines
+15
to
+18
There was a problem hiding this comment. In cases such as with illegal content, you would probably want to not have anyone be able to view it. There should be some other endpoint or a field on the It may also be desired for moderators to be able to delete content from homeservers as well with a similar convention as above. |
||
|
|
||
| ### Server behavior | ||
| Servers MUST check that the requester has a power level higher than or equal to | ||
|
There was a problem hiding this comment. Does this imply that in a typical DM room, where both users are admins, redactions are always allowed to be uncovered if that's technically possible? There was a problem hiding this comment. That's a good point. I guess it could have a separate power level or some special casing to disallow in DM rooms. Federation isn't involved, so servers could just arbitrarily decide that if a room looks like a DM, then nobody gets to view redacted content. |
||
| the `redact` power level in the room. If the requester has a lower power level, | ||
| the server returns a standard error response with the `M_FORBIDDEN` code. If | ||
| the server no longer has the event content, the endpoint returns `M_NOT_FOUND` | ||
| like it currently always does for redacted events. | ||
|
|
||
|
There was a problem hiding this comment. Does it work in the same way independent on whether the redaction was performed by the user themselves or a room mod/admin? Is it possible for an admin to "confirm" redaction, suggesting to their server that the unredacted data can already be deleted? There was a problem hiding this comment. Yes. I don't think room admins need special power, but it could make sense for server admins to have it. That might be a separate MSC though. |
||
| ### Client behavior | ||
| Clients should still always remove content when receiving a redaction event, | ||
| but if the user has sufficient power, the client may show a button to re-fetch | ||
| and display the redacted event content. | ||
|
|
||
| ## Alternatives | ||
| ### Separate key in power levels | ||
| Instead of reusing the `redact` power level, a new key could be introduced. | ||
| A new key would have the advantage of allowing more precise control. However, | ||
| it would have to be added to the event authorization rules, as otherwise | ||
| anyone with enough power to send `m.room.power_levels` could change the level | ||
| for the new key, even if it required a higher level than what the user has. | ||
|
|
||
| ## Potential issues | ||
| * Servers aren't required to keep redacted content for any time, and it would | ||
| be rather confusing UX if the show redacted content button in clients never | ||
| worked. | ||
| * If a server doesn't get the event before it's redacted, the server may never | ||
| get the unredacted content. | ||
|
|
||
| ## Unstable prefix | ||
| While this MSC is not in a released version of the spec, implementations should | ||
| use `net.maunium.msc2814.include_redacted_content` as the query parameter name. | ||
| Additionally, servers should advertise support using the `net.maunium.msc2814` | ||
tulir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| flag in `unstable_features` in the `/versions` endpoint. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dendrite immediately deletes the event content from the database for the record. This does not affect attachments though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There would need to be a timespan defined in the spec for the amount of time servers should retain redacted messages. It doesn't make any sense for them to be kept forever, but as mentioned, having varying behaviors between homeservers would result in a lot of confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it have to be defined in the spec? I don't think the spec should force homeservers to retain for a specific amount of time. It is configurable in Synapse so there are already many servers out there with different values.
I guess the error message for M_NOT_FOUND could include "This server retains redacted messages for X days" or something.