[e2e issue] Decrypt error related to new device creation

[Jean-PhilippeR]

I find another issue related to e2e and new device creation
B has device device_1
In the past B and C has joined same rooms but they have no more room in common now
-> So for C, list of device of B is [device_1]

B starts application on a new device called device_2
-> C is not notified of this new device because no more common room with B

A invites B and C in room XX
B is the first to accept the invitation from device_2
B checks all room members who has joined the room XX to notify a a new device

B only sends a message new device to A because A is the only one who has already joined the room.
(request matrix.whitenoise.ch/_matrix/client/unstable/sendToDevice/m.new_device)

C accepts the invitation
C checks all room members who has joined the room XX and from now will check new device announcement from A and B but not before
So for C, list of device of B is still [device_1]
So when C sends a message in room XX, it cannot be decrypt from device_2.
If my analysis is correct, is it an already known issue?

[Jean-PhilippeR]

This issue is related to tracking devices for other matrix users
To avoid missing some devices, a first solution is to ask again all devices of all rooms members when we joins a new room by using POST /_matrix/client/unstable/keys/query but it is quite bandwith consuming

Can we imagine a light version of this request to only get current list fo device_ID for users?
Client will call this request when it joins a room, check which device_id is missing or has been deleted and ask complete information only for needed device?

We can also imagine to associate a track value for list of device of each user? This track value will be init to 0 and will be incremented each time a device is added or removed?
example:
1st device created : device_tracker[user XX] = 0
2nd device created :device_tracker[user XX] = 1
1st device deleted : device_tracker[user XX] = 2
3rd device created : device_tracker[user XX] = 3

This device_tracker would be returned in room state -> for each room member
So that when a client joins a room, he could easily check if its image of device list is obsolet or not for each room member.

[Jean-PhilippeR]

Other remark: if a device cannot decrypt a message because of unknown inbound session, it could be useful to create a new device request to ask to device emitter the next megolm key associated to a megolm session.
So that we miss one message but not the other ones.
What do you think of these proposals?

[manuroe]

The issue is similar to element-hq/element-web#2305.
We have a test testLeftAndJoinedBob that almost checks this scenario.

[richvdh]

tracking this as element-hq/element-web#4983 on the riot-web side