Is your feature request related to a problem? Please describe.
From a web application like NEAR BOS I often need to interact with multiple contracts. For example I want to interact with DevHUB, which use it's own contract in addition to the common near.social contract.
Today the wallet selector only supports signing into one contract, but you can still use walletConnection.requestSignIn from near-api-js and point to a different key store, so that you can store access keys for multiple smart contracts in the same web app. This method is only supported by browser wallets, as it requires a wallet url to redirect to, but for other wallets can even create an AddKey transaction and store it in a separate keystore.
This approach works in this pull request to NearSocialVM.
The downside is that if you need to create an AddKey transaction, the wallets does not always offer a clear message to the user on what's going on. HERE wallet gives you the standard login experience with the message an application is requesting limited access to your account, but Meteor just shows an AddKey transaction which is not very clear.
Describe the solution you'd like
The wallet selector should provide a way to always use the standard login flow when signing into an additional contract. Instead of having to check for what the wallet supports in the VM, there should be call to the wallet selector for signing in to an additional contract.
Describe alternatives you've considered
I have implemented the pull request to NearSocialVM as referred above, and I also did some initial proof of concept in the wallet selector some time ago in this draft Pull Request. Even though it's possible to get quite far without changes in the Wallet Selector, the issue of providing the standard login flow for all wallets is blocked without changes in the Wallet Selector.
Acceptance criteria
As a minimum it should be possible to trigger the login flow of the currently selected wallet for a BrowserLocalStorageKeyStore that you provide from the web app. This way it is possible for the consuming web app to manage wallet connections to additional contracts.
Is your feature request related to a problem? Please describe.
From a web application like NEAR BOS I often need to interact with multiple contracts. For example I want to interact with DevHUB, which use it's own contract in addition to the common
near.socialcontract.Today the wallet selector only supports signing into one contract, but you can still use
walletConnection.requestSignInfrom near-api-js and point to a different key store, so that you can store access keys for multiple smart contracts in the same web app. This method is only supported by browser wallets, as it requires a wallet url to redirect to, but for other wallets can even create anAddKeytransaction and store it in a separate keystore.This approach works in this pull request to NearSocialVM.
The downside is that if you need to create an
AddKeytransaction, the wallets does not always offer a clear message to the user on what's going on. HERE wallet gives you the standard login experience with the messagean application is requesting limited access to your account, but Meteor just shows anAddKeytransaction which is not very clear.Describe the solution you'd like
The wallet selector should provide a way to always use the standard login flow when signing into an additional contract. Instead of having to check for what the wallet supports in the VM, there should be call to the wallet selector for signing in to an additional contract.
Describe alternatives you've considered
I have implemented the pull request to NearSocialVM as referred above, and I also did some initial proof of concept in the wallet selector some time ago in this draft Pull Request. Even though it's possible to get quite far without changes in the Wallet Selector, the issue of providing the standard login flow for all wallets is blocked without changes in the Wallet Selector.
Acceptance criteria
As a minimum it should be possible to trigger the login flow of the currently selected wallet for a
BrowserLocalStorageKeyStorethat you provide from the web app. This way it is possible for the consuming web app to manage wallet connections to additional contracts.