Let megolm session keys be available to devices added by invited users since the point they are invited

[ara4n]

Closely related to matrix-org/matrix-spec-proposals#2286 - when we invite someone into a room we should give them enough megolm session data to let them decrypt the messages that they should be able to view before joining (if any).

[ara4n]

Hopefully fixed by matrix-org/matrix-js-sdk#666, matrix-org/matrix-react-sdk#2042 and matrix-org/synapse#3484.

[ara4n]

These don't quite work for the edge case when an invited user adds devices after being invited but before they join, as they don't know who to tell about their new devices. So either it means invited users have to unilaterally participate in a room DAG (which is a (D)DoS vector), or we need to share megolm keys to the new devices after the event (if it turns out that the new devices are verified).

Current conclusion is that we use KS reqs to paper over this edge case (perhaps with custom UX to reflect what's going on).

https://docs.google.com/document/d/1_wDoDQ02JLZwYeVb-QVPylnJUXJVTZ9bNoGHd_Go6Zg/edit has notes on this.

(Or alternatively we just make it a feature that you can't read history before you join a room, like WhatsApp does)

EDIT: this has been expanded out into matrix-org/synapse#3504

[ara4n]

Reopening as this hasn't quite been fixed yet; we need to handle the scenario where a user adds a device after the user is invited to the room.

[ara4n]

These don't quite work for the edge case when an invited user adds devices after being invited but before they join, as they don't know who to tell about their new devices. So either it means invited users have to unilaterally participate in a room DAG (which is a (D)DoS vector), or we need to share megolm keys to the new devices after the event (if it turns out that the new devices are verified).

Thinking more about this while implementing MSC2444 peeking, I think the conclusion above is wrong (better late than never).

1. When a user is invited to a room, the existing users will check its devicelist and encrypt for its devices.
2. If more users (and devices) join the room, they will see the invited user and query its device list and encrypt for its current devices.
3. If the invited user adds more devices, it could tell every server whose users we're speaking Olm to about the new devices. This would solve the problem that the invited user doesn't know the updated membership of the room via the DAG. However, it would mean the server would have to keep track of the servers/users its users are talking Olm with (which is a bit of a layering violation, given Olm should really be opaque to the server - it's just to-device messages).
4. Alternatively: we could let the joined servers send lone membership events to the invited server(s) for the room, as if the invited servers were doing an MSC2444-style peek filtered to membership events (which has the advantage of notifying the invited server if the invite state changes - e.g. by the inviter leaving the room). This seems very desirable given it would solve If an inviter leaves a 1:1 before the invitee joins, we should cancel the invite matrix-org/matrix-spec#462. The invited server would then know to tell the joined users about changes in the invited user's devicelist.

4 seems like a pretty nice solution to this, i think?

[ara4n]

(Alternatively, we could burn device lists with fire, as this whole problem only happens due to their fragility)

[ShadowJonathan]

Alternatively to 4: We could also have peeks be allowed for rooms a user gets invited to, see my comment on the peek MSC

[YousefED]

Closely related to matrix-org/matrix-spec-proposals#2286 - when we invite someone into a room we should give them enough megolm session data to let them decrypt the messages that they should be able to view before joining (if any).

I ran into this issue as well, but as we're a few years later am wondering how the proposed solution would match with specs like matrix-org/matrix-spec-proposals#3083; there are now more ways to be granted access to a room. If you're granted access by a room because you're passing a join rule, I would argue it should be similar to being invited to the room directly; i.e.: you should also be able to decrypt messages from that point onwards.

edit: just found this which seems related: element-hq/element-meta#646

[uhoreg]

Device dehydration might partially solve this issue (though we also need to consider what happens when the dehydrated device gets rotated).
Could also solve this by having the sender do a /keys/query on every invited user before sending (though we need to make sure the sender's server queries the invited user's server, rather than relying on cache).

[richvdh]

The history on this is very confusing. I don't think there's anything here that isn't covered by element-hq/synapse#3504, so I'm going to close it.