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. We need a migration path for existing users. A toast or somewhere in settings. Security update available=> we need the 4S passphrase in order to generate a random key for dehydrated device and store it in 4S.

[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.