From 9080c5f87f87e7461d0350843b2fc6c82d079d6a Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 18 Aug 2020 08:53:34 -0600 Subject: [PATCH] Revert "Revert "MSC2033: Adding a device_id to /account/whoami"" --- proposals/2033-whoami-device-id.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 proposals/2033-whoami-device-id.md diff --git a/proposals/2033-whoami-device-id.md b/proposals/2033-whoami-device-id.md new file mode 100644 index 00000000..bac804c1 --- /dev/null +++ b/proposals/2033-whoami-device-id.md @@ -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.