element-hq / element-hq/element-meta
E2E Device lists can get out of sync with the devices actually present in a room.
- Dominant language
- No language data
- Stars
- 112
- Forks
- 25
- Avg merge
- 6h 6m
- Merged PRs (30d)
- 4
Description
Device lists can get out of sync for various reasons:
* [x] https://github.com/element-hq/element-web/issues/4527
* [x] https://github.com/matrix-org/synapse/issues/8631
* [ ] https://github.com/element-hq/synapse/issues/11374
* [ ] https://github.com/element-hq/synapse/issues/3503
* [ ] https://github.com/element-hq/synapse/issues/3504
* [ ] https://github.com/element-hq/element-meta/issues/2314
* [ ] https://github.com/element-hq/element-meta/issues/2594
* [ ] https://github.com/element-hq/synapse/issues/18550
* [ ] https://github.com/element-hq/element-web/issues/30149
* [ ] https://github.com/element-hq/element-meta/issues/3009
* [x] https://github.com/element-hq/backend-internal/issues/286
---
@richvdh [mentioned in #e2e-dev](https://matrix.to/#/!uewiilduiDRfPomIha:matrix.org/$1530816424114903zVTzS:matrix.org) the other day that he'd had some thoughts on how to address these:
> \ richvdh: so, you think we should make devicelists a best effort thing
\ and if A sends to B and B’s server sees B has added devices (whether B is invited or joined)
\ then B’s server should tell A, “actually, encrypt for more devices plz”
\ and you hope that turnaround happens fast enough that A is still there and will then handle whatever verification is needed to do so?
\ yup
\ you would probably apply more intelligence, so that A can choose not to send to certain of B's devices
\ so, alongside the message, A would say "I'm targeting generation # 123 of B's device list", and B's server would compare the generation number rather than the actual target devices
However, this doesn't help solve the issue on https://github.com/vector-im/riot-web/issues/2713#issuecomment-402989021 where the messages would only be sent to the invited user after they joined the room (at which point it's too late for the sender to re-encrypt them for missing devices). I wonder if a solution could be to support subscribing to arbitrary user devices using simple pubsub semantics: Alice can subscribe to updates about Bob's device list (using an API which hopefully is resilient to unreliable connectivity between Alice & Bob's HSes). Updates could only be allowed if Alice can 'see' Bob (i.e. if Alice has invited Bob or shares a room with him), although this is a pretty weak security mechanism given anyone can invite anyone (although at least Bob would know that Alice was stalking him).
I've opened this issue to track the idea of rethinking how devicelists work (again) before they get baked into the spec.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.