-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Filesystem Recovery #427
Comments
One thing that should be explored here is how much of the recovery process should happen in Webnative and what should be handled by the app. For example, the app should probably create and parse recovery kits. Webnative should validate the contents of the recovery kit and prepare the filesystem. Not clear where registering a new user and assigning them the filesystem should take place. |
Related to #427 |
@icidasset you perhaps wanted to link another issue, right? You've just linked to the same issue :) |
@matheus23 Whoops, thanks 🤣 I meant #304 |
Summary
Problem
Account recovery is possible through Dashboard and re-linking the Auth Lobby, but is not available directly from Webnative.
Impact
Apps that use app-owned auth do not have a recovery mechanism.
Solution
As a first baseline, let's implement filesystem recovery in Webnative.
Note that this form of recovery only needs to recover private files and assign the filesystem to a new user. Full account recovery updates the user's account with a new DID by relying on email challenge to authenticate the user. We would like to support full account recovery eventually, but as a first pass we will only need filesystem recovery.
Detail
Describe alternatives you've considered
We've considered full account recovery, but the Webnative app template does not collect emails. A future version may include the full email loop, but for now we will only implement filesystem recovery where a user has their username and read key available in a recovery kit.
The text was updated successfully, but these errors were encountered: