You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This proposal also counts for Element Android and iOS)
One of the things i'd like to see in Element is that it is more "proactive" when requesting encryption keys, I wouldn't wanna keep tapping/clicking "request encryption keys" for days on end to get the history of a E2EE chat on another device.
Instead, I'd like Element to do this for me, automatically recognising some encryption keys arent loaded, asking to other users/devices, and marking that it has been asked, patiently waiting for a response, all in the "background".
In addition to this, Element would need to be "smarter" with how it requests keys, it should "poke" other cross-user devices with a single request, to see if they are online at any one time to be able to respond to the key request, and do congestion control with back-n-forth of requesting keys that way, to not overload whatever device is on the receiving end of these requests.
Overall, these two mechanisms would smooth out rough E2EE experiences, allowing the suggestion of "it will fix itself over time" to actually work out (as long as devices are online that're asking and answering key requests)
The text was updated successfully, but these errors were encountered:
(This proposal also counts for Element Android and iOS)
One of the things i'd like to see in Element is that it is more "proactive" when requesting encryption keys, I wouldn't wanna keep tapping/clicking "request encryption keys" for days on end to get the history of a E2EE chat on another device.
Instead, I'd like Element to do this for me, automatically recognising some encryption keys arent loaded, asking to other users/devices, and marking that it has been asked, patiently waiting for a response, all in the "background".
In addition to this, Element would need to be "smarter" with how it requests keys, it should "poke" other cross-user devices with a single request, to see if they are online at any one time to be able to respond to the key request, and do congestion control with back-n-forth of requesting keys that way, to not overload whatever device is on the receiving end of these requests.
Overall, these two mechanisms would smooth out rough E2EE experiences, allowing the suggestion of "it will fix itself over time" to actually work out (as long as devices are online that're asking and answering key requests)
The text was updated successfully, but these errors were encountered: