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

MSC2033: Adding a device_id to /account/whoami #2033

Merged
merged 2 commits into from
Aug 18, 2020
Merged
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
30 changes: 30 additions & 0 deletions proposals/2033-whoami-device-id.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# Proposal to include device IDs in `/account/whoami`

There are some use cases (namely using
[Pantalaimon with bots](https://github.com/matrix-org/pantalaimon/issues/14))
which could benefit from knowing the `device_id` associated with a token.


## Proposal

The `/account/whoami` endpoint receives an additional response field for the `device_id`
associated with the access token. The field is optional because appservice users may not
have a real device associated with them. Non-appservice users should always have a device
associated with them.

Access tokens are already associated with at most 1 device, and devices are associated with
exactly 1 access token. Because of this, we do not need to worry about multiple devices
causing problems. For more information, see
https://matrix.org/docs/spec/client_server/r0.4.0.html#relationship-between-access-tokens-and-devices

*Note*: Pantalaimon would likely require a `device_id` be returned and error requests
otherwise. This should be considered expected behaviour by Pantalaimon in the MSC author's
opinion.


## Tradeoffs

We could introduce a `/device/whoami` endpoint, however that is a less superior option. Most
calls to `/device/whoami` would additionally need to call `/account/whoami` to determine the
user ID of the account. We had might as well bundle the two pieces of information into the
same request.