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,73 @@ | ||
| # 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. | ||
|
Comment on lines
+21
to
+22
There was a problem hiding this comment. Is there a reason to reuse this power level instead of making a new one? In some communities you may want to verify that moderators are doing their job properly and not being corrupt. Having a separate power level would allow people to verify this without having permissions to redact content themselves. Or you might want the opposite where perhaps mods can delete messages, but you might not want other mods to be able to see them, and only let admins do so. |
||
|
|
||
| * If the requester doesn't have permission to view the event in general (e.g. | ||
| not participating in the room), the server retuns a `M_NOT_FOUND` error the | ||
| same way it did before this proposal. | ||
| * If the requester doesn't have sufficient power level to view redacted events, | ||
| the server returns a standard error response with the `M_FORBIDDEN` code. | ||
| * If the requester has all the necessary privileges to view the content, but | ||
| the server does not have the unredacted content, the server should return one | ||
| of the following error codes: | ||
| * `M_UNREDACTED_CONTENT_DELETED`: The server has deleted the content from its | ||
| database. The server may optionally include a `m.content_keep_ms` key in | ||
| the error that specifies how long it keeps unredacted content. | ||
|
There was a problem hiding this comment. Suggestions for better names for |
||
| * `M_UNREDACTED_CONTENT_NOT_RECEIVED`: The server never received the | ||
| un-redacted content (this can happen if federation is slow and the event | ||
| was redacted before it reached the server) | ||
|
|
||
|
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. | ||
|
|
||
| ### Implementation notes | ||
| Some server implementations have implementation-specific concepts of "server | ||
| admins". Such servers should allow server admins to bypass the power level | ||
| checks involved in viewing redacted events. However, like other similar | ||
| implementation details, there won't be any standard way for clients to | ||
| determine if they can view a redacted message through server admin privileges. | ||
|
|
||
| ## 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.msc2815.include_redacted_content` as the query parameter name, | ||
| and `net.maunium.msc2815.content_keep_ms` in the error response. The error | ||
| codes should use `NET.MAUNIUM.MSC2815` as a prefix instead of `M`. | ||
|
|
||
| Additionally, servers should advertise support using the `net.maunium.msc2815` | ||
| 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.