Provide standard login flow for multiple contracts

[petersalomonsen]

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.

[kujtimprenkuSQA]

Hi, @petersalomonsen thank you for raising this issue.

As you stated above the wallet selector supports signIn only with one contractId.

Supporting sign-in with multiple contracts by triggering the current signIn flow of the wallet(s) will not make it possible to get the desired result because there are a few limitations:

• The BrowserLocalStorageKeyStore near-api-js can only store one LAK per walletConnection for an account prefix:accountId:network (this means every time you try to signIn with a new contractId it will override the old one)
• Wallet Selector does not create or manage the LAK, this is handled by the wallet(s) through either NAJ or some wallets have their own way to save keys on localStorage.

[petersalomonsen]

Hi @kujtimprenkuSQA ,

In NearSocial/VM#156, which will be released on BOS these days, we use multiple keystores to overcome the limitation of near-api-js only being able to store one LAK per walletConnection. That was also the idea when originally I started this work in the wallet selector as you can see in #887 .

It is true that the wallet selector does not manage local access keys, but it is possible to manage usage of multiple walletConnections and keystores from the Wallet selector implementations. I believe it should be possible for the wallet selector provide the feature of managing multiple connections, through a single API method.

So maybe add an additional method to the wallet selector API for adding local function access keys for additional contracts?