Create LAKBrowserKeystore to facilitate tracking multiple LAKs for a single account at once

[MaximusHaximus]

Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines on issues.

Description

• Similar to BrowserLocalStorageKeystore, in that keys should be stored in LocalStorage
• Track LAK keyPairs by [networkId, accountId, contractId]
• Persist into browser local storage similarly to BrowserLocalStorageKeystore
• Ensure that no interference occurs with existing keys stored by BrowserLocalStorageKeystore
• Ideally, we would create in such a way as to be backwards compatible with existing keys stored by BrowserLocalStorageKeystore, so our new keystore could discover and load existing keys stored using a BrowserLocalStorageKeystore for the same app prefix.

Has this been requested on GitHub Discussions?

No response

Motivation

• Our current keystores are unable to handle cases where dapps need users to interact with multiple contracts for the same account, or in cases where multiple dapps live in the same context (such as Discovery), each with their own LAK (limited access key).
• The central issue is that the existing keystores only allow 1 storage of a single key per [networkId, accountId], but we need to be able to store a key per [networkId, accountId, contractId].
• With the recent approval of NEP-438, we have added the ability for dapps to request to be signed in to multiple contracts in a single sign-in wallet request. This keystore will be critical to facilitate the dapp being able to actually use those keys, whether it is implemented by the dapp author, inside of wallet modules in the wallet-selector context, or is used by wallet extensions directly to store keys.

API design

API will shadow BrowserLocalStorageKeyStore (see: https://github.com/near/near-api-js/blob/master/packages/keystores-browser/src/browser_local_storage_key_store.ts) but with the addition of contractId as part of the identifier used to store keys in localstorage, to ensure that multiple keys can be stored for the same [networkId, accountId], as long as each key has a different target contract.

Self-service

• I'd be willing to contribute and develop this feature myself.

Related Issues

Preview Give feedback

No tasks being tracked yet.