From 41efaefa097669be018b5a4f092e3ec513f318f2 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Wed, 9 Feb 2022 17:45:58 +0000 Subject: [PATCH 01/11] MSCXXXX: User status --- proposals/XXXX-user-status.md | 103 ++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 proposals/XXXX-user-status.md diff --git a/proposals/XXXX-user-status.md b/proposals/XXXX-user-status.md new file mode 100644 index 000000000..b1c6f25aa --- /dev/null +++ b/proposals/XXXX-user-status.md @@ -0,0 +1,103 @@ +# MSCXXXX: User status endpoint + +Matrix clients sometimes need a way to display additional information about a +user. For example, when interacting with a Matrix user, it might be useful for +clients to show whether this user has been deactivated, or even exists at all. + +Currently clients are forced to resort to hacks to try to derive this +information. Some, for example, check whether a user has a profile (display +name, avatar) set when trying to send an invite, which means that if a user +doesn't have any profile information (which is valid under the Matrix +specification), the inviter might be warned that the user might not exist. + +## Proposal + +Two new endpoints are added to the specification, one to the client-server API +and one to the server-server API. + +### `GET /_matrix/client/v1/user/status` + +This endpoint requires authentication via an access token. + +This endpoint takes a `user_id` query parameter indicating which user(s) to look +up the status of. This parameter may appear multiple times in the request if the +client wishes to look up the statuses of multiple users at once. + +If no error arises, the endpoint responds with a body using the following +format: + +```json +{ + "@user1:example.com": { + "exists": true, + "deactivated": false + }, + "@user2:example.com": { + "exists": false + } +} +``` + +Each top-level key in the response maps to one of the `user_id` parameter(s) +in the request. For each user: + +* `exists` is a boolean that indicates whether the user exists. +* `deactivated` is a boolean that indicates whether the user has been + deactivated. Omitted if `exists` is `false`. + +If one or more user(s) is not local to the homeserver this request is performed +on, the homeserver must attempt to retrieve user status using the federation +endpoint described below. + +Below is how this endpoint behaves in case of errors: + +* If no `user_id` parameter is provided, the endpoint responds with a 400 status + code and a `M_MISSING_PARAM` error code. +* If one or more of the `user_id` parameter(s) provided cannot be parsed as a + valid Matrix user ID, the endpoint responds with a 400 status code and a + `M_INVALID_PARAM` error code. + +### `GET /_matrix/federation/v1/query/user_status` + +This endpoint behaves in an identical way to the client-side endpoint described +above. + +### `m.user_status` capability + +Some server administrators might not want to disclose too much information about +their users. To support this use case, homeservers must expose a `m.user_status` +capability to tell clients whether they support retrieving user status via the +client-side endpoint described above. + +## Potential issues + +It is not clear how to show users whose status could not be retrieved because of +federation issue, a missing or blocked federation endpoint, or an incomplete +response from the remote homeserver, in the client-side endpoint's response. I +have considered omitting them from the response entirely, or adding an +additional `success` boolean to each user's status to indicate whether status +for this user could be retrieved, but I am not entirely satisfied with either +solution. I am open to suggestions on this point. + +## Security considerations + +Should a server administrator not want to disclose their users' statuses through +the federation endpoint described above, they should use a reverse proxy or +similar tool to prevent access to the endpoint. On top of this, homeserver +implementations may implement measures to only respond with an empty JSON object +`{}` in this case. + +## Unstable prefixes + +Until this proposal is stabilised in a new version of the Matrix specification, +implementations should use the following paths for the endpoints described in +this document: + +| Stable path | Unstable path | +|--------------------------------------------|---------------------------------------------------------------------| +| `/_matrix/client/v1/user/status` | `/_matrix/client/unstable/org.matrix.mscXXXX/user/status` | +| `/_matrix/federation/v1/query/user_status` | `/_matrix/federation/unstable/org.matrix.mscXXXX/query/user_status` | + +Additionally, implementations should use the unstable identifier +`org.matrix.mscXXXX.user_status` instead of `m.user_status` for the client-side +capability. From 55a4727e182f05203bdcc0cb5bf4824aaeaea75b Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Wed, 9 Feb 2022 17:47:33 +0000 Subject: [PATCH 02/11] MSC number --- proposals/{XXXX-user-status.md => 3720-user-status.md} | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) rename proposals/{XXXX-user-status.md => 3720-user-status.md} (95%) diff --git a/proposals/XXXX-user-status.md b/proposals/3720-user-status.md similarity index 95% rename from proposals/XXXX-user-status.md rename to proposals/3720-user-status.md index b1c6f25aa..b21750c65 100644 --- a/proposals/XXXX-user-status.md +++ b/proposals/3720-user-status.md @@ -1,4 +1,4 @@ -# MSCXXXX: User status endpoint +# MSC3720: User status endpoint Matrix clients sometimes need a way to display additional information about a user. For example, when interacting with a Matrix user, it might be useful for @@ -95,9 +95,9 @@ this document: | Stable path | Unstable path | |--------------------------------------------|---------------------------------------------------------------------| -| `/_matrix/client/v1/user/status` | `/_matrix/client/unstable/org.matrix.mscXXXX/user/status` | -| `/_matrix/federation/v1/query/user_status` | `/_matrix/federation/unstable/org.matrix.mscXXXX/query/user_status` | +| `/_matrix/client/v1/user/status` | `/_matrix/client/unstable/org.matrix.msc3720/user/status` | +| `/_matrix/federation/v1/query/user_status` | `/_matrix/federation/unstable/org.matrix.msc3720/query/user_status` | Additionally, implementations should use the unstable identifier -`org.matrix.mscXXXX.user_status` instead of `m.user_status` for the client-side +`org.matrix.msc3720.user_status` instead of `m.user_status` for the client-side capability. From d6bcb043c95d40b65b8cbefcd48a0920cf52c9ef Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 10 Feb 2022 10:57:55 +0000 Subject: [PATCH 03/11] Incorporate review --- proposals/3720-user-status.md | 44 ++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/proposals/3720-user-status.md b/proposals/3720-user-status.md index b21750c65..dfa33be49 100644 --- a/proposals/3720-user-status.md +++ b/proposals/3720-user-status.md @@ -15,7 +15,7 @@ specification), the inviter might be warned that the user might not exist. Two new endpoints are added to the specification, one to the client-server API and one to the server-server API. -### `GET /_matrix/client/v1/user/status` +### `GET /_matrix/client/v1/user_status` This endpoint requires authentication via an access token. @@ -28,23 +28,38 @@ format: ```json { - "@user1:example.com": { - "exists": true, - "deactivated": false + "user_statuses": { + "@user1:example.com": { + "exists": true, + "deactivated": false + }, + "@user2:example.com": { + "exists": false + }, }, - "@user2:example.com": { - "exists": false - } + "failures": [ + "@user3:example.com", + "@user4:otherexample.com" + ] } ``` -Each top-level key in the response maps to one of the `user_id` parameter(s) -in the request. For each user: +The `user_statuses` object in the response lists all statuses that could +successfully be retrieved. Each key in this object maps to one of the `user_id` +parameter(s) in the request. For each user: * `exists` is a boolean that indicates whether the user exists. * `deactivated` is a boolean that indicates whether the user has been deactivated. Omitted if `exists` is `false`. +The `failures` object in the response lists all users for which no status could +be retrieved for any reason (e.g. federation issues, missing federation +endpoint, missing user in the remote server's response, etc). + +The combination of the lists of user IDs from `user_statuses` and `failures` +must match the full list of user IDs provided in the request via `user_id` +parameters. + If one or more user(s) is not local to the homeserver this request is performed on, the homeserver must attempt to retrieve user status using the federation endpoint described below. @@ -71,13 +86,10 @@ client-side endpoint described above. ## Potential issues -It is not clear how to show users whose status could not be retrieved because of -federation issue, a missing or blocked federation endpoint, or an incomplete -response from the remote homeserver, in the client-side endpoint's response. I -have considered omitting them from the response entirely, or adding an -additional `success` boolean to each user's status to indicate whether status -for this user could be retrieved, but I am not entirely satisfied with either -solution. I am open to suggestions on this point. +I'm not fully sure this is the right name for this feature as it can easily be +confused with status messages. An alternative name from previous work around +this feature was "user info", but I thought it might be a bit vague. I'm open to +suggestions on this point. ## Security considerations From 2d3aec8d41cd2fe4fd658e4ef71f2e4d63e05479 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 10 Feb 2022 11:29:00 +0000 Subject: [PATCH 04/11] Rename into account status --- ...-user-status.md => 3720-account-status.md} | 67 +++++++++---------- 1 file changed, 31 insertions(+), 36 deletions(-) rename proposals/{3720-user-status.md => 3720-account-status.md} (53%) diff --git a/proposals/3720-user-status.md b/proposals/3720-account-status.md similarity index 53% rename from proposals/3720-user-status.md rename to proposals/3720-account-status.md index dfa33be49..123f4e701 100644 --- a/proposals/3720-user-status.md +++ b/proposals/3720-account-status.md @@ -1,8 +1,9 @@ -# MSC3720: User status endpoint +# MSC3720: Account status endpoint Matrix clients sometimes need a way to display additional information about a user. For example, when interacting with a Matrix user, it might be useful for -clients to show whether this user has been deactivated, or even exists at all. +clients to show whether this user's account has been deactivated, or even exists +at all. Currently clients are forced to resort to hacks to try to derive this information. Some, for example, check whether a user has a profile (display @@ -15,20 +16,20 @@ specification), the inviter might be warned that the user might not exist. Two new endpoints are added to the specification, one to the client-server API and one to the server-server API. -### `GET /_matrix/client/v1/user_status` +### `GET /_matrix/client/v1/account_status` This endpoint requires authentication via an access token. -This endpoint takes a `user_id` query parameter indicating which user(s) to look -up the status of. This parameter may appear multiple times in the request if the -client wishes to look up the statuses of multiple users at once. +This endpoint takes a `user_id` query parameter indicating which user account(s) +to look up the status of. This parameter may appear multiple times in the +request if the client wishes to look up the statuses of multiple users at once. If no error arises, the endpoint responds with a body using the following format: ```json { - "user_statuses": { + "account_statuses": { "@user1:example.com": { "exists": true, "deactivated": false @@ -44,25 +45,26 @@ format: } ``` -The `user_statuses` object in the response lists all statuses that could +The `account_statuses` object in the response lists all statuses that could successfully be retrieved. Each key in this object maps to one of the `user_id` -parameter(s) in the request. For each user: +parameter(s) in the request. For each account: -* `exists` is a boolean that indicates whether the user exists. -* `deactivated` is a boolean that indicates whether the user has been +* `exists` is a boolean that indicates whether an account exists with this user + ID. +* `deactivated` is a boolean that indicates whether the account has been deactivated. Omitted if `exists` is `false`. -The `failures` object in the response lists all users for which no status could -be retrieved for any reason (e.g. federation issues, missing federation +The `failures` object in the response lists all user IDs for which no status +could be retrieved for any reason (e.g. federation issues, missing federation endpoint, missing user in the remote server's response, etc). The combination of the lists of user IDs from `user_statuses` and `failures` must match the full list of user IDs provided in the request via `user_id` parameters. -If one or more user(s) is not local to the homeserver this request is performed -on, the homeserver must attempt to retrieve user status using the federation -endpoint described below. +If one or more account(s) is not local to the homeserver this request is +performed on, the homeserver must attempt to retrieve account status using the +federation endpoint described below. Below is how this endpoint behaves in case of errors: @@ -72,7 +74,7 @@ Below is how this endpoint behaves in case of errors: valid Matrix user ID, the endpoint responds with a 400 status code and a `M_INVALID_PARAM` error code. -### `GET /_matrix/federation/v1/query/user_status` +### `GET /_matrix/federation/v1/query/account_status` This endpoint behaves in an identical way to the client-side endpoint described above. @@ -80,22 +82,15 @@ above. ### `m.user_status` capability Some server administrators might not want to disclose too much information about -their users. To support this use case, homeservers must expose a `m.user_status` -capability to tell clients whether they support retrieving user status via the -client-side endpoint described above. - -## Potential issues - -I'm not fully sure this is the right name for this feature as it can easily be -confused with status messages. An alternative name from previous work around -this feature was "user info", but I thought it might be a bit vague. I'm open to -suggestions on this point. +their users. To support this use case, homeservers must expose a +`m.account_status` capability to tell clients whether they support retrieving +account status via the client-side endpoint described above. ## Security considerations -Should a server administrator not want to disclose their users' statuses through -the federation endpoint described above, they should use a reverse proxy or -similar tool to prevent access to the endpoint. On top of this, homeserver +Should a server administrator not want to disclose information about their users +through the federation endpoint described above, they should use a reverse proxy +or similar tool to prevent access to the endpoint. On top of this, homeserver implementations may implement measures to only respond with an empty JSON object `{}` in this case. @@ -105,11 +100,11 @@ Until this proposal is stabilised in a new version of the Matrix specification, implementations should use the following paths for the endpoints described in this document: -| Stable path | Unstable path | -|--------------------------------------------|---------------------------------------------------------------------| -| `/_matrix/client/v1/user/status` | `/_matrix/client/unstable/org.matrix.msc3720/user/status` | -| `/_matrix/federation/v1/query/user_status` | `/_matrix/federation/unstable/org.matrix.msc3720/query/user_status` | +| Stable path | Unstable path | +|-----------------------------------------------|------------------------------------------------------------------------| +| `/_matrix/client/v1/account_status` | `/_matrix/client/unstable/org.matrix.msc3720/account_status` | +| `/_matrix/federation/v1/query/account_status` | `/_matrix/federation/unstable/org.matrix.msc3720/query/account_status` | Additionally, implementations should use the unstable identifier -`org.matrix.msc3720.user_status` instead of `m.user_status` for the client-side -capability. +`org.matrix.msc3720.account_status` instead of `m.account_status` for the +client-side capability. From 813b379f88822466900b528abd09c4299dc565bc Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 10 Feb 2022 11:38:18 +0000 Subject: [PATCH 05/11] Missed one when renaming --- proposals/3720-account-status.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index 123f4e701..0ba4b9fef 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -79,7 +79,7 @@ Below is how this endpoint behaves in case of errors: This endpoint behaves in an identical way to the client-side endpoint described above. -### `m.user_status` capability +### `m.account_status` capability Some server administrators might not want to disclose too much information about their users. To support this use case, homeservers must expose a From 1c3417c2edc3d69e009ca74c25e3671e12fadfc8 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Fri, 11 Feb 2022 18:10:01 +0000 Subject: [PATCH 06/11] Only allow local users on the federation endpoint --- proposals/3720-account-status.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index 0ba4b9fef..0578d1baf 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -77,7 +77,11 @@ Below is how this endpoint behaves in case of errors: ### `GET /_matrix/federation/v1/query/account_status` This endpoint behaves in an identical way to the client-side endpoint described -above. +above, with the additional following error case: + +* If one or more of the `user_id` parameter(s) does not match a local account, + the endpoint responds with a 400 status code and a `M_INVALID_PARAM` error + code. ### `m.account_status` capability From 87853fdd41020101b5b320536d35e969d58da2f3 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Mon, 14 Feb 2022 10:12:17 +0000 Subject: [PATCH 07/11] Improve wording around federation failure --- proposals/3720-account-status.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index 0578d1baf..9f7202f95 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -79,9 +79,9 @@ Below is how this endpoint behaves in case of errors: This endpoint behaves in an identical way to the client-side endpoint described above, with the additional following error case: -* If one or more of the `user_id` parameter(s) does not match a local account, - the endpoint responds with a 400 status code and a `M_INVALID_PARAM` error - code. +* If one or more of the `user_id` parameter(s) does not match an account that + belong to the homeserver receiving the request, the endpoint responds with a + 400 status code and a `M_INVALID_PARAM` error code. ### `m.account_status` capability From 92120dd3601dae3438cc9a28b62a969f14264763 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Wed, 16 Feb 2022 18:03:56 +0000 Subject: [PATCH 08/11] Be consistent with MSC3550 --- proposals/3720-account-status.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index 9f7202f95..bc7b7afc4 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -95,8 +95,8 @@ account status via the client-side endpoint described above. Should a server administrator not want to disclose information about their users through the federation endpoint described above, they should use a reverse proxy or similar tool to prevent access to the endpoint. On top of this, homeserver -implementations may implement measures to only respond with an empty JSON object -`{}` in this case. +implementations may implement measures to respond with a 403 status code and a +`M_FORBIDDEN` error code in this case. ## Unstable prefixes From 30732a40ec3031afe47528f3a362eded520be281 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 17 Feb 2022 17:27:10 +0000 Subject: [PATCH 09/11] Change the endpoints to use POST instead of GET --- proposals/3720-account-status.md | 54 +++++++++++++++++++++----------- 1 file changed, 35 insertions(+), 19 deletions(-) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index bc7b7afc4..7384d304b 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -16,13 +16,23 @@ specification), the inviter might be warned that the user might not exist. Two new endpoints are added to the specification, one to the client-server API and one to the server-server API. -### `GET /_matrix/client/v1/account_status` +### `POST /_matrix/client/v1/account_status` This endpoint requires authentication via an access token. -This endpoint takes a `user_id` query parameter indicating which user account(s) -to look up the status of. This parameter may appear multiple times in the -request if the client wishes to look up the statuses of multiple users at once. +The body of this endpoint includes a `user_ids` field which is an array listing +all of the users account(s) to look up the status of: + +```json +{ + "user_ids": [ + "@user1:example.com", + "@user2:example.com", + "@user3:example.com", + "@user4:otherexample.com" + ] +} +``` If no error arises, the endpoint responds with a body using the following format: @@ -46,8 +56,8 @@ format: ``` The `account_statuses` object in the response lists all statuses that could -successfully be retrieved. Each key in this object maps to one of the `user_id` -parameter(s) in the request. For each account: +successfully be retrieved. Each key in this object maps to one of the user IDs +listed in the request. For each account: * `exists` is a boolean that indicates whether an account exists with this user ID. @@ -59,8 +69,7 @@ could be retrieved for any reason (e.g. federation issues, missing federation endpoint, missing user in the remote server's response, etc). The combination of the lists of user IDs from `user_statuses` and `failures` -must match the full list of user IDs provided in the request via `user_id` -parameters. +must match the full list of user IDs provided in the request. If one or more account(s) is not local to the homeserver this request is performed on, the homeserver must attempt to retrieve account status using the @@ -68,19 +77,19 @@ federation endpoint described below. Below is how this endpoint behaves in case of errors: -* If no `user_id` parameter is provided, the endpoint responds with a 400 status +* If no `user_ids` field is provided, the endpoint responds with a 400 status code and a `M_MISSING_PARAM` error code. -* If one or more of the `user_id` parameter(s) provided cannot be parsed as a - valid Matrix user ID, the endpoint responds with a 400 status code and a - `M_INVALID_PARAM` error code. +* If one or more of the user ID(s) provided cannot be parsed as a valid Matrix + user ID, the endpoint responds with a 400 status code and a `M_INVALID_PARAM` + error code. -### `GET /_matrix/federation/v1/query/account_status` +### `POST /_matrix/federation/v1/account_status` This endpoint behaves in an identical way to the client-side endpoint described above, with the additional following error case: -* If one or more of the `user_id` parameter(s) does not match an account that - belong to the homeserver receiving the request, the endpoint responds with a +* If one or more of the user ID(s) provided does not match an account that + belongs to the homeserver receiving the request, the endpoint responds with a 400 status code and a `M_INVALID_PARAM` error code. ### `m.account_status` capability @@ -90,6 +99,13 @@ their users. To support this use case, homeservers must expose a `m.account_status` capability to tell clients whether they support retrieving account status via the client-side endpoint described above. + +## Alternatives + +A previous version of this proposal used `GET` requests instead of `POST`. +However, while `GET` is semantically more correct here, the methods have been +changed to `POST` so user IDs don't leak into reverse proxy logs. + ## Security considerations Should a server administrator not want to disclose information about their users @@ -104,10 +120,10 @@ Until this proposal is stabilised in a new version of the Matrix specification, implementations should use the following paths for the endpoints described in this document: -| Stable path | Unstable path | -|-----------------------------------------------|------------------------------------------------------------------------| -| `/_matrix/client/v1/account_status` | `/_matrix/client/unstable/org.matrix.msc3720/account_status` | -| `/_matrix/federation/v1/query/account_status` | `/_matrix/federation/unstable/org.matrix.msc3720/query/account_status` | +| Stable path | Unstable path | +|-----------------------------------------|------------------------------------------------------------------| +| `/_matrix/client/v1/account_status` | `/_matrix/client/unstable/org.matrix.msc3720/account_status` | +| `/_matrix/federation/v1/account_status` | `/_matrix/federation/unstable/org.matrix.msc3720/account_status` | Additionally, implementations should use the unstable identifier `org.matrix.msc3720.account_status` instead of `m.account_status` for the From d8292f0d5189e4012576624e4a9b075467fd373c Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Mon, 21 Feb 2022 17:49:44 +0000 Subject: [PATCH 10/11] Prevent a server from overwriting another server's account status --- proposals/3720-account-status.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index 7384d304b..94c053b98 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -99,7 +99,6 @@ their users. To support this use case, homeservers must expose a `m.account_status` capability to tell clients whether they support retrieving account status via the client-side endpoint described above. - ## Alternatives A previous version of this proposal used `GET` requests instead of `POST`. @@ -108,12 +107,23 @@ changed to `POST` so user IDs don't leak into reverse proxy logs. ## Security considerations +### Allowing servers to refuse to share account statuses + Should a server administrator not want to disclose information about their users through the federation endpoint described above, they should use a reverse proxy or similar tool to prevent access to the endpoint. On top of this, homeserver implementations may implement measures to respond with a 403 status code and a `M_FORBIDDEN` error code in this case. +### Overwriting the statuses of another server's account + +When processing the response from a request to the federation endpoint described +in this proposal, homeservers implementations must verify that every account the +remote homeserver has provided a status for belongs to the remote homeserver. +For any account for which this isn't the case, the status provided by the remote +homeserver must be ignored. This is to prevent mischievous homeservers from +trying to overwrite the status of accounts that don't belong to them. + ## Unstable prefixes Until this proposal is stabilised in a new version of the Matrix specification, From bda488084ec0c7d762d6760e7442f54082a77cc9 Mon Sep 17 00:00:00 2001 From: Brendan Abolivier Date: Thu, 1 Sep 2022 15:26:07 +0100 Subject: [PATCH 11/11] Incorporate review --- proposals/3720-account-status.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/3720-account-status.md b/proposals/3720-account-status.md index 94c053b98..bee1fdea4 100644 --- a/proposals/3720-account-status.md +++ b/proposals/3720-account-status.md @@ -83,6 +83,9 @@ Below is how this endpoint behaves in case of errors: user ID, the endpoint responds with a 400 status code and a `M_INVALID_PARAM` error code. +If the `user_ids` field is an empty list, the server responds with a `200 OK` +status and an empty body (`{}`). + ### `POST /_matrix/federation/v1/account_status` This endpoint behaves in an identical way to the client-side endpoint described