Flow Providers: Non-custodial wallets #28 - Milestone 3 - Zay Codes Submission #88
+6
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Flow Providers: Non-custodial wallets #28 - Milestone 3
Description
This PR is for issue #28 .
Previous milestone submissions here: #54 #84
Submission Links & Documents
How keys are stored and used
When a user imports a new private key for their flow account, the wallet will prompt for the user's password. The password is required and used to encrypt the private key. The private key is then stored in chrome.storage.local (persistent browser storage limited to the scope of the installed extension. The stored
keyVault
looks like the following:encrypted({ pubKey1: privKey1, pubKey2: privKey2 })
When a user would like to use the wallet, they must
unlock
the wallet. Unlocking requires the same password that was previously set on the first run at importing a Flow account to the wallet. The password provided was used as the encryption key to the aforementioned keyVault, and so password validity is checked against the ability to decrypt that object. If decryption is successful, the wallet is considered unlocked and the decrypted keyVault is stored in chrome.storage.session for temporary storage, or until the wallet is manually locked.Also, a separate flow account is held in local storage unencrypted, and may have many public keys attached to it. The publickey to privatekey mapping is separate to the flow accounts. When running a transaction with a flow account, the wallet accesses the flow account, gets the first >=1000 weight public key, retrieves its corresponding private key, and then makes the needed signature.
Some GIFs of the extension working:
Authn + Preauthz + Authz
Popups are ugly right now, because we can not modify them per FCL. Currently using FCL's pop-up for the service type, but plan to use the new extension one when it is more ready, which we can then customize to look better:
https://gyazo.com/a0a2e39ad5fa474ee95fa97692ddd157
Popup UI
https://gyazo.com/99421332be463db4dcfa1ea133b2101c
Source and readme with information is here: https://github.com/Zay-Codes-Lab/zay-wallet <- Currently private, will be opened up later. Ping me on discord for fastest permission add (amit#4491)
Requirements Check
npm run test
Other Details
Same info as last milestone - the extension is currently reassigning chrome.storage.session to chrome.storage.local because FCL is unable to support Manifest V3 at this time. We have not yet, but will either expire the chrome.storage.local storage of unlocked keyVaults, or wait for chrome.storage.session to work prior to considering releasing anything publicly.