Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4260: Reporting users (Client-Server API) #2093

Merged
merged 7 commits into from
Mar 21, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelogs/client_server/newsfragments/2093.new
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Add `POST /_matrix/client/v3/users/{userId}/report` as per [MSC4260](https://github.com/matrix-org/matrix-spec-proposals/pull/4260).
6 changes: 6 additions & 0 deletions content/client-server-api/modules/report_content.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,3 +29,9 @@ is in before accepting a report.
based on whether or not the reporting user is joined to the room. This is
because users can be exposed to harmful content without being joined to a
room. For instance, through room directories or invites.

{{% added-in v="1.14" %}} Similarly, servers MUST NOT restrict user reports
based on whether or not the reporting user is joined to any rooms that the
reported user is joined to. This is because users can be exposed to harmful
content without being joined to a room. For instance, through user
directories or invites.
97 changes: 90 additions & 7 deletions data/api/client-server/report_content.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,9 @@ paths:
properties:
reason:
type: string
description: The reason the room is being reported.
description: The reason the room is being reported. May be blank.
required:
- reason
required: true
security:
- accessTokenQuery: []
Expand Down Expand Up @@ -88,12 +90,11 @@ paths:
Reports an event as inappropriate to the server, which may then notify
the appropriate people. The caller must be joined to the room to report
it.

It might be possible for clients to deduce whether an event exists by
timing the response, as only a report for an event that does exist
will require the homeserver to check whether a user is joined to
the room. To combat this, homeserver implementations should add
a random delay when generating a response.

Furthermore, it might be possible for clients to deduce whether a reported
event exists by timing the response. This is because only a report for an
existing event will require the homeserver to do further processing. To
combat this, homeservers MAY add a random delay when generating a response.
operationId: reportEvent
parameters:
- in: path
Expand Down Expand Up @@ -164,6 +165,88 @@ paths:
}
tags:
- Reporting content
"/users/{userId}/report":
post:
x-addedInMatrixVersion: "1.14"
summary: Report a user as inappropriate.
description: |-
Reports a user as inappropriate to the server, which may then notify
the appropriate people. How such information is delivered is left up to
implementations. The caller is not required to be joined to any rooms
that the reported user is joined to.

Clients may wish to [ignore](#ignoring-users) users after reporting them.

Clients could infer whether a reported user exists based on the 404 response.
Homeservers that wish to conceal this information MAY return 200 responses
regardless of the existence of the reported user.

Furthermore, it might be possible for clients to deduce whether a reported
user exists by timing the response. This is because only a report for an
existing user will require the homeserver to do further processing. To
combat this, homeservers MAY add a random delay when generating a response.
operationId: reportUser
parameters:
- in: path
name: userId
description: The user being reported.
required: true
example: "@someguy:example.com"
schema:
type: string
format: mx-user-id
pattern: "^@"
requestBody:
content:
application/json:
schema:
type: object
example: {
"reason": "this makes me sad"
}
properties:
reason:
type: string
description: The reason the room is being reported. May be blank.
required:
- reason
required: true
security:
- accessTokenQuery: []
- accessTokenBearer: []
responses:
"200":
description: |
The user has been reported successfully or the server chose
to not disclose whether the users exists.
content:
application/json:
schema:
type: object
examples:
response:
value: {}
"404":
description: |-
The user was not found on the homeserver.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "The user was not found."
}
"429":
description: This request was rate-limited.
content:
application/json:
schema:
$ref: definitions/errors/rate_limited.yaml
tags:
- Reporting content
servers:
- url: "{protocol}://{hostname}{basePath}"
variables:
Expand Down