MSC4226: Reports as rooms

[Gnuxie]

Rendered

Signed-off-by: Gnuxie Gnuxie@protonmail.com

---

In line with matrix-org/matrix-spec#1700, the following disclosure applies:

This MSC was written in a volunteer capacity without any $funding 🐾

[Gnuxie]

Jassuko suggested:

Can you figure a way to allow linking to multiple events instead of just a single event? Some times more context would be nice for decision making and gaining a full picture might need pointers to events that are not immediately next to each other.

[Gnuxie]

I replied:

normally one event is enough just to anchor it and we expect moderators to go looking for the surrounding context, but yeah as you say that's a problem when stuff is spread out. it's difficult because i don't know if any client has the ux that would let you select multiple events like that? But I guess it would be possible to either allow them to send more events with context or add an array or something, idk

[Gnuxie]

We should do this and add a flag to the MSC4121 role for whether they should receive reports

[turt2live]

Implementation requirements:

• Client
• Server

[deepadmax]

I imagine that a report room could be end-to-end encrypted; the subject may be sensitive. If that's the case, you may not want to store the reason unencrypted either. What if the reason would be stored elsewhere? A state event could refer to the event ID of the message to be used as the reason; by default, it would be the first message. Another benefit to storing it as state rather than in the creation event is that the reason can be changed later to better describe the problem.

[Gnuxie]

#4226 (comment)

I imagine that a report room could be end-to-end encrypted; the subject may be sensitive. If that's the case, you may not want to store the reason unencrypted either. What if the reason would be stored elsewhere? A state event could refer to the event ID of the message to be used as the reason; by default, it would be the first message. Another benefit to storing it as state rather than in the creation event is that the reason can be changed later to better describe the problem.

(@deepadmax thank you for reading the MSC :) btw it's not a big deal but next time you open a thread somewhere by clicking on the file so that we can reply easily ^^)

[Gnuxie]

This is true, if the report was sent in messages once the report room was created then it could be end to end encrypted. However, doing so would complicate the MSC. (See power level

matrix-spec-proposals/proposals/4226-reports-as-rooms.md

Lines 153 to 168 in 8703e19

	### Power level event
	In order to give the moderators and server admins control over the
	report room, and protect the moderators and server admins from further
	abuse, there are specific requirements on the power level event that
	need to be fulfilled when creating the room. These may be checked by
	clients or servers check before they show the report to report
	moderators, in order to maintain safety (See [Consistency
	checks](#consistency-checks)).
	1. The reporter needs to immediately remove their ambient authority in
	the first `m.room.power_levels` event sent to the room by setting
	their power level to `-1`.
	2. Any report moderators that have been invited to the room need to be
	given the "admin" role or a power level of `100`.

).

Currently the reporter is supposed to deliberately yield power level in the room in order to give the report moderators control. The client's of the report moderator are supposed to check that the power level has been yielded immediately. The idea being that this would minimize attempts to harass report moderators by flooding them with reports that have abusive content.

Maybe it is overly cautious though. If clients can hide messages behind spoiler text, and can blur images (both things that Nheko and Element web can do for instance) by default, then it might not be so bad to allow the reporter to send messages to the room.

It is probably then worthwhile turning the report context into a timeline event and allowing multiple context events to be sent within one report (so this would replace the mixin m.report.* that is present within the m.room.create event, and they could be encrypted too).

It would be nice to know if you or anyone else have thoughts about that before I rewrite these parts of the MSC?

[Gnuxie]

Doing this would close off the route of backwards compatibility though when reports are intended to be created by servers when the legacy reporting client server api endpoints are used. Unless we just allow those to be sent without encryption (because then at least one server in this instance is already able to intercept the contents of the report).