For now, smartphone users which only use or own one device, the risk of loosing their keys and access is quite high. In order for those users to comfortably participate in fission enabled dapps, this challenge will because at least for us quite a high priority.
Do you have ideas of a very simple implemented mvp in the direction of social recovery, without rolling out the fully featured key-management, planned over the next months?
From the conceptual side I quite like, how Argent is solving this issue with guardians.
I agree recovery is important for addressing a wider audience beyond web3-knowledgeable devs.
Currently there are two ways to improve your keys not getting lost; the first is linking multiple devices.
The second is adding auth.fission.codes to your homepage on your phone; this way, as a progressive web app (PWA) the OS will backup your keys it stores, piggybacking on phone OS recovery.
We know this is not sufficient for most users though. Passwordless login is new to many; the right way to go, but obviously hard to combine with web3-recovery.
Because recovery options depend on the user, (and as such the audience of the application that introduces them to Fission), a good way forward - imo - may be to build recovery as an app itself on Fission.
This way users can chose themselves, how and when to opt for any or all recovery options; and apps can guide their audience to the most suitable one.
Some patterns for backup app(s) then, in no particular order:
(multiple devices; implemented)
“paperwallet”, user explicitly securely stores information to recover account
server-aided, by default Fission
social recovery (optionally with additional passphrase)
All the above patterns can be constructed from Shamir Secret Sharing:
Shamir secret split an access file;
optionally protect one or more shares by encrypting with an AES key. (this allows for crypto-hard server-aided recovery)
Argent does a great job on the User flow for making this understandable. They combine a second feature in the guardian, beyond recovery: signing limit protections, eg. requiring their signatures for higher amounts etc.
To securely manage keys natively from the browser environment with Fission, we’re using UCAN’s to securely instruct a trusted co-signer whether or not co-sign and execute transactions signed from the browser (using BLS instead of a multisig ACL)
“The second is adding auth.fission.codes to your homepage on your phone; this way, as a progressive web app (PWA) the OS will backup your keys it stores, piggybacking on phone OS recovery.”
I havn’t thought about this one, I quite like that proposal and its a great workaround as well as definitely a good starters explanation, we can offer the users during onboarding / registration.
