Production-ready encrypted room history on invite

[andybalaam]

Continuing from the prototype at #2685 , make this work in Element clients with proper UI.

(Does not cover 3rd-party invites.)

(We think that we can continue using the media API and leave the key bundles on the server since they are encrypted and have similar secrecy to key backups.)

• (clients) History sharing: set up a labs flag allowing people to opt in #2871
• (doc) History sharing: update MSC4268 #2872
• (doc) Inform authors of MSC3911 that we are using media that is linked to to-device messages (in a complex way), not room events
• (n/a) Do we need to paginate key bundle data? No - we can already stream on upload and download to/from the media API, and file sizes should be <10MB even for big rooms.
• (sdk) History sharing: support for indexeddb matrix-org/matrix-rust-sdk#5107
• (clients) End-to-end tests. Probably for web, via playwright?
• (clients, sdk) History sharing: sending UI #2874
• (clients) History sharing: UX for telling users that history may be shared #2875
• (clients, sdk) History sharing: Support indicating in the key bundle which keys we deliberately didn't send, and display in UI with appropriate message #2876
• (sdk) History sharing: merge megolm sessions if we get keys from two sources matrix-org/matrix-rust-sdk#5108
• (sdk) History sharing: store details of the provenance of a shared megolm session matrix-org/matrix-rust-sdk#5109
• (clients) History sharing: show "as presented by Bob" in the UI #2877
• (sdk) History sharing: store provenance of keys in the key backup matrix-org/matrix-rust-sdk#5110
• (sdk) History sharing: download keys from backup before sending key bundle matrix-org/matrix-rust-sdk#5111
• (sdk) History sharing: support restarting import of keys after a crash or being stopped matrix-org/matrix-rust-sdk#5112
• (sdk) History sharing: On the client, clean up key bundle data when we've used it, or after we think we don't need it matrix-org/matrix-rust-sdk#5113
• (sdk) History sharing: Handle devices we can't establish an Olm session with matrix-org/matrix-rust-sdk#5114

Designs:

• Web
• iOS
• Android

[mxandreas]

Given we have this, what purpose does #749 still serve, if any?

[andybalaam]

Given we have this, what purpose does #749 still serve, if any?

• #749 Share history
  • #39 Share history on invite
    • #2685 Prototype of share on invite
    • #2829 Production ready share on invite

[mxandreas]

This is fine, but I think the description of the tickets need to be updated to realize that this is the case.

[andybalaam]

This is fine, but I think the description of the tickets need to be updated to realize that this is the case.

I updated this item's title - which other descriptions need updating - after a quick glance they looked ok to me?

[americanrefugee]

Final designs:

• Web
• iOS
• Android

[andybalaam]

Summary of our meeting with design. This just confirms what is in the description, but writing it here explicitly in case it clarifies anything:

• When a user sends an invite we should block saying something like "preparing room history" until the keys are collected and sent
• When receiving an invite with key history, this should be transparent to the user, with old messages appearing as UTDs with a message something like "Waiting for this message". If the client is killed in the middle of this process, it should resume when restarted.
• When I am invited to a room that has history sharing turned on, I should see a dismissable banner telling me that messages I send now will be visible to FUTURE room members. This should also be noted in the room info panel.
• When I am already in a room and an admin changes the room history sharing setting to turn it on, I should see the same banner (and it should be noted in the room info panel)
• When room history has been shared with me, then every message whose key I received from the inviter (instead of the sender of the original message) should have a small "(i)" icon next to it that explains to me that this message was sent by the inviter. (It could have been forged by them.)
• Sometimes when we collect keys to send with an invite, we will deliberately exclude some (e.g. because the room settings at the time it was sent said don't share history). Normally, these message will be invisible, because the server will prevent the actual encrypted message from being delivered, but occasionally these might show up. We should show them as UTDs, but with a custom message, something like "This message is not visible because it was sent when Share Room History was turned off".