MSC4457: Generic reporting API#4457
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client (using new API)
- Server (offering new API)
turt2live
left a comment
turt2live
left a comment
There was a problem hiding this comment.
Bringing over comments from the private draft doc (all authored by me).
| *Note:* Servers MAY use `404 M_NOT_FOUND` and `403 M_FORBIDDEN`. The remaining error codes MUST only | ||
| be returned in applicable cases. This optionality is to allow servers to customize their operations | ||
| to their individual regulatory requirements and needs. For example, a server might choose to validate | ||
| that a user can see an event, but also choose *not* to return an error if they can’t (instead, it’d | ||
| get flagged internally on the report). |
There was a problem hiding this comment.
"MUST only" is trying to carry a requirement for a future compliance suite: a server which always returns a 404 for local users, even if they exist, is non-compliant.
| exactly a report should be routed to. Implementations SHOULD NOT assume that reports will only go to | ||
| a single place in the future. This is important for implementations which provide the endpoint as | ||
| separate software from the bulk of the homeserver, as otherwise that software might assume that it’s | ||
| only going to have to populate a single destination queue. |
There was a problem hiding this comment.
"Implementations SHOULD NOT assume..." might make more sense as future MSCs are written. I'm mostly trying to say "don't treat this endpoint as only reporting to server admins - it'll have routing information later, and your software will need to be capable of sending communications as needed"
| * Possibly adding evidence to someone else's report, similar to a character witness statement. | ||
| * This may be better handled by a new `information` report type. |
There was a problem hiding this comment.
this may further be best to just leave to the backend. Individual users can submit distinct complaints that are deduplicated/aggregated on the backend.
| // Cannot exceed 1024 bytes (before trimming whitespace). | ||
| // | ||
| // REQUIRED (cannot be an empty string, after trimming whitespace). | ||
| "description": "This user is spamming", |
There was a problem hiding this comment.
For some harms it doesn't make sense to require a description - the subject is enough to make a decision. Requiring it is likely to cause some portion of reports to have content like "."
| ``` | ||
|
|
||
| *Author's note*: The choice to use `regarding` is deliberate for a bit of natural language: a user is | ||
| **reporting** a **complaint** **regarding** something/someone which caused **harm**. `description` |
There was a problem hiding this comment.
I think this is slightly clunky, although not too important.
- Reporting an Appeal (or other type of object) doesn't make as much sense
- The user is making a complaint with a subject and a description, and the moderator looks at the subject of the complaint, not the regarding of the complaint.
| * Returning a report ID only to discard it is a bit strange. | ||
| * Internal handling of reports may be difficult. | ||
| * Limiting to authenticated users (including guests) may prove to be an issue. | ||
|
|
There was a problem hiding this comment.
- A user filling out a report only to hit a forbidden or rate limited error code, wasting the work / losing the data
* Remove MSC3215 (Report to Moderators) labs feature T&S does not believe this is used, and intends to replace it during Reporting v2 anyway. Original MSC: matrix-org/matrix-spec-proposals#3215 New (WIP) MSC: matrix-org/matrix-spec-proposals#4468 (This PR/commit doesn't add MSC4468 support because it's unclear if we should use MSC4468 directly or via another endpoint like MSC4457) [MSC4457]: matrix-org/matrix-spec-proposals#4457 * Remove unused state: isRoomEncrypted
2 participants
Rendered