matrix-org / matrix-org/matrix-spec

Should a device be reported if no keys have been uploaded for it?

Open
#967 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

clarification
Dominant language
HTML
Stars
330
Forks
150
Avg merge
2h 21m
Merged PRs (30d)
3

Description

**Link to problem area**: https://spec.matrix.org/v1.1/server-server-api/#get_matrixfederationv1userdevicesuserid

Consider the following scenario:

1. `@alice:alice.com` registers a new device `D`.
2. Alice does __not__ upload encryption keys for this device (yet).
3. `bob.com` calls `GET alice.com/_matrix/federation/v1/user/devices/@alice:alice.com` to fetch Alice's device data.

In the response to `bob.com`,
- should `D` be included in the list of Alice's devices?
- (with a `keys: DeviceKeys` value that's empty).
- or should `D` be omitted from the list of Alice's devices?

I expected the former, because the spec summarises `GET /_matrix/federation/v1/user/devices/{userId}` as

> Gets information on all of the user’s devices

but the latter seems to be how Synapse behaves. Is this a bug in Synapse?

More generally, there seem to be two distinct concepts that the spec is blurring:

- A device as in a session ID, created with `/login` and `/register`
- A device as in the pair `(session_ID, public_cryptographic_data)`.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked Matrix Server-Server API section for GET /_matrix/federation/v1/user/devices/{userId}, then compare its wording with the Synapse behavior described in the issue. Clarify whether devices without uploaded encryption keys must be included and distinguish session-created devices from devices with public cryptographic data in the specification.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.