60 lines
3.1 KiB
Markdown
60 lines
3.1 KiB
Markdown
# Proposal for more granular profile error codes
|
|
|
|
Clients and other applications in the wider Matrix ecosystem may wish to do a "proof of life"
|
|
check on users to see if they exist. For clients, this may be done ahead of inviting a user to
|
|
a room to assist the user in picking the right target. Other use cases may include a bridge which
|
|
is attempting to map from the 3rd party protocol to Matrix instead of the other way around.
|
|
|
|
Currently the best way to perform this check is to ask for the target user's profile, however
|
|
this option is not great. Under the current specification, servers can return 404 for a wide
|
|
range of reasons which are not all that helpful.
|
|
|
|
|
|
## Proposal
|
|
|
|
We make `GET /_matrix/client/$version/profile/$userId` return more granular responses to aid
|
|
the specific use cases outlined above:
|
|
|
|
* 200 OK - The profile was found and supplied by the server (no change from the current spec).
|
|
* 404 / `M_USER_NOT_FOUND` - The server acknowledges that the user was not found/does not exist.
|
|
* 404 / `M_PROFILE_NOT_FOUND` - The server acknowledges that the user does exist, but has an
|
|
otherwise empty profile.
|
|
* 404 / `M_PROFILE_UNDISCLOSED` - The server is refusing to disclose details about this user. Clients
|
|
cannot assume that the user does or does not exist.
|
|
|
|
The rationale for keeping all 3 error codes as `404 Not Found` is to maintain backwards compatibility
|
|
with clients which may already be calling these endpoints.
|
|
|
|
Currently, `M_NOT_FOUND` is returned for when a profile is empty or when the requested user was not
|
|
found. This proposal is splitting that out into `M_USER_NOT_FOUND` and `M_PROFILE_NOT_FOUND` for added
|
|
clarity to clients.
|
|
|
|
To reiterate, `M_PROFILE_UNDISCLOSED` is not to be assumed as an admission that the requested user does
|
|
or does not exist. The server could be refusing to disclose the user/profile for a variety of reasons
|
|
including prevention of user ID harvesting or to maintain a highly private environment.
|
|
|
|
In all cases, the server would be expected to proxy the error code returned by remote servers if the
|
|
profile request ends up being for a remote user.
|
|
|
|
Clients which do check for existence are encouraged to provide the user with a "continue anyways"
|
|
option where possible. For example, if the client checks that users exist before inviting them, it
|
|
may wish to warn the user that one or more targets might not be actual users in the system but should
|
|
still let the user invite them anyways.
|
|
|
|
|
|
## Alternative Solutions
|
|
|
|
#### Add a new proof of life endpoint
|
|
|
|
Adding another endpoint further complicates the spec for such a small feature. Additionally, clients
|
|
may actually end up wanting the profile returned from the endpoint and shouldn't have to call two
|
|
different endpoints to get highly related information.
|
|
|
|
|
|
## Potential issues
|
|
|
|
If accepted, it is possible that a private federation of servers results in only ever `M_PROFILE_UNDISCLOSED`
|
|
errors, regardless of who is requesting the information. In these cases, clients may wish to consider
|
|
supporting a configuration option for not checking whether a user exists or not to avoid bombarding the
|
|
user with warnings constantly.
|