Dehydrated device Settings

[BillCarsonFr]

Related to MSC2687
and MSC3814

Dehydrated device is adding the possibility for a user to still access e2ee messages that was sent to him when he had 0 active sessions (logged out from everywhere).
In order to do that, we declare a sort of virtual device on the account that will stack up to_devices messages until you decide to claim it. In order to claim it you need a passphrase (the virtual device is saved encrypted serverside)

Impact for users

In the settings, users will always see an additional device in their device list

This would be very confusing for the user.

We have to find another place to store that dehydrated device.
We might have some managment action on the device?
@uhoreg if you see things to add, or other UX need

Proposed Solution

1. Hide the dehydrated device from the device list in setting as well as in user profile.
2. Device dehydration: upgrade existing user accounts to add a dehydrated device element-web#29080: a migration path for existing users.

[BillCarsonFr]

@amshakal we should find a place to gave some feedback if something went wrong.
Like if we tried to rehydrate in background and it fails (the key is not correct).
We might just want a section in security (doesn't have to be a global modal). From there the only action could be to reset the dehydrated device, i.e create a new one, and we need 4S passphrase for that

[uhoreg]

We should also figure out how to enable/disable device dehydration.

[BillCarsonFr]

My idea was to bundle that with 4S. Not sure we need more fine grain configuration.

[pmaier1]

My idea was to bundle that with 4S. Not sure we need more fine grain configuration.

Yes. We should make device dehydration as transparent as possible to users - no new settings if we can avoid it. Agree to bind it to the backup. The dehydrated device also should not be visible in device lists.

[uhoreg]

Element Web currently hides the dehydrated device from the list of devices (in the session manager and in the user side panel), but displays a separate indication that there is a dehydrated device. We don't have any special handling in Element X, but we believe that the dehydrated device will not show up in MAS. We still should have some sort of indication of its presence in the UI somewhere.

Some additional considerations:

• we have an indication that there is a dehydrated device present, but we don't have an indication of whether the client is creating dehydrated devices (might not be necessary for general users, but maybe should have something for developers)
• since creating the initial dehydrated device requires adding a new secret (the dehydration key) to SSSS, it requires the SSSS key, so we only do so if the user logs in and uses SSSS to verify. If they verify using a different device, we don't have the SSSS key so we can't create the dehydration key. We'll need to consider how to allow existing users to enable device dehydration.

[uhoreg]

This is mostly done on Element Web, except for things that have separate issues, so closing. Tasks for Element X should be created separately, when we start work on dehydration in Element X.