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.
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
.
Servers MUST check that the requester has a power level higher than or equal to
the redact
power level in the room.
- 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 am.content_keep_ms
key in the error that specifies how long it keeps unredacted content.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)
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.
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.
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.
- 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.
While this MSC is not in a released version of the spec, implementations should
use fi.mau.msc2815.include_unredacted_content
as the query parameter name, and
fi.mau.msc2815.content_keep_ms
in the error response. The error codes should
use FI.MAU.MSC2815
as a prefix instead of M
.
Additionally, servers should advertise support using the fi.mau.msc2815
flag
in unstable_features
in the /versions
endpoint.