Newly joined users can't decrypt messages from existing users in an e2e room.

[ara4n]

Lots of instances this evening in various sets of existing users not being able to see messages from other users, despite everyone being on olm 1.3.0.

My stream of consciousness is something like:

it seems that when a device first speaks in a room, it sends an m.room_key via toDevice
but i don't see it sending m.new_device anywhere
and meanwhile other devices never send it a m.room_key
so it simply isn't aware of the ongoing sessions.
which feels to me like matrix-org/matrix-js-sdk#204 is entirely broken
i just don't see the logic anywhere when a device receives an m.room_key that it says "ooh, new device! i'd better send it my room_key data too!"
unless it actually saw an m.new_device. except we seem quite shy about ever sending m.new_device. especially if we've been lurking in the room pre-e2e? or on an older version of olm?
so it feels to me like we should be much more aggressive about sending new_device announcements, as well as interpreting room_keys from unknown devices as... a new_device.

[ara4n]

(closely related to #2204, which has the same symptoms)

[ara4n]

So, I just reproduced one failure mode using basically the same steps as #2204, although presumably the root cause is different.

Account on the left is @matthewtest30. Account on the right is @matthewtest31.

• 30 creates a new room.
• 30 turns on encryption
• 30 says something
• 30 invites 31
• 31 joins
• 31 says something; 30 decrypts it ok.
• 30 says something; 31 can't decrypt it.

Looking at the console logs, it seems 30 sees a room_key when 31 starts speaking, so knows about 31's session.
31 however never sees a room_key, nor a new_device from 30, so doesn't know about 30's session.

Naively, it looks to me like we're forgetting to send room_keys to new devices when they join rooms. And meanwhile the reliability mechanisms for sending new_devices when we see unknown session (matrix-org/matrix-js-sdk#204) are broken too.

Both on latest develop with olm 1.3.0.

[ara4n]

(the reason I'm testing this flow is that it's the classic and probably most common use case of setting up a 1:1 encrypted chat)

[ara4n]

confirmed fixed