feat: Add signInMulti method

[kujtimprenkuSQA]

Description

This PR is about adding the signInMulti method to the public API of the wallets in Wallet Selector based on near/NEPs#428 .

• Added interfaces in wallet.types for the signInMulti.
• Added signInMulti in each wallet, it initially throws when calling this method.
• Added logic in the core package to allow sign-in with multiple contracts.
• Updated modal-ui and modal-ui-js to pass the list of contracts to the signInMulti method.
• Added docs for signInMulti.

Wallets that support signInMulti in this PR

• none

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

Type of change.

• FIX - a PR of this type patches a bug.
• FEATURE - a PR of this type introduces a new feature.
• BUILD - a PR of this type introduces build changes.
• CI - a PR of this type introduces CI changes.
• DOCS - a PR of this type introduces DOCS improvement.
• STYLE - a PR of this type introduces style changes.
• REFACTOR - a PR of this type introduces refactoring.
• PERFORMANCE - a PR of this type introduces performance changes.
• TEST - a PR of this type adds more tests.
• CHORE - a PR introduces other changes than the specified above.

[MaximusHaximus]

Added comments around keeping state for signInMulti() separate from signIn() -- we need to make sure that a combination of signIn() and signInMulti() being called with the same contracts will result in sane and deterministic behaviour.

[MaximusHaximus]

Rather than having every wallet module be required by convention to implement a signInMulti() method that throw's an error if it isn't supported, can we instead not add a signInMulti() method in the modules that do not support it, and make this decorator check if the method exists and throw the error

throw new Error(
        `The signInMulti method is not supported by ${metadata.name}`
      );

if it hasn't been implemented?

This has two benefits:

1. If any wallet module doesn't implement the method for whatever reason, callers will always get a consistent error thrown instead of there being a '_signInMulti() is not a function' type of error thrown from our attempt to call it in those cases
2. We don't need to inform wallet module authors about the need to add a stub, ensure their modules have the stub during code reviews, etc. -- we can treat the lack of implementation as a 'not supported'.

[kujtimprenkuSQA]

Addressed it in this commit: 8121e5e

[MaximusHaximus]

We need to handle cases where:

1. A dapp might call signIn() for a contract that was previously signed into using signInMulti(). For example, let's say that a dapp uses 3 contracts regularly, and their access key allowance expires for just one of those three contracts. The dapp author does not need to request the user re-signIn to all 3 contracts using signInMulti() -- they would just request signIn() for the one contract whose allowance has been used up.
2. A dapp might call signInMulti() with an array that includes a contract that they had previously signed in to using signIn()

If we always store results from signInMulti() in contracts and results from signIn() in contract, we will end up with duplicate entries in these keys when a mixture of calls is used by the dapp developer -- we need to have one-and-only-one entry for a given contract across these two fields (contract and contracts) to make sure everything is sane and deterministic.

[amirsaran3]

This PR should solve these issues: #847

[ailisp]

Hi @kujtimprenkuSQA @MaximusHaximus What is the status of this PR? Our team is recently tried to add a relevant feature and discovered this. WIP branch. I wonder if we can move this forward

[kujtimprenkuSQA]

Hi @kujtimprenkuSQA @MaximusHaximus What is the status of this PR? Our team is recently tried to add a relevant feature and discovered this. WIP branch. I wonder if we can move this forward

Hi, this PR is not ready to be merged yet as we still need this additional PR #847 related to the comment #811 (comment) to be reviewed and make a decision if we should go with it or not since it will introduce breaking changes in Wallet Selector.

As of right now, we are not aware if any wallet supports the signInMulti.
For browser wallets I think this update in NAJ is needed: near/near-api-js#1153 there was some work done related to it: near/near-api-js#1163

[petersalomonsen]

OK, so maybe I may move forward with my experiments in here then: #887 ?

This approach does not require change in wallets, and does not introduce any breaking change to the wallet selector. It simply offers the option to add a function access key to another contract, and store it in a separate keystore ( near-api-js supports multiple keystore with different prefixes ).

As you can see from the test case there's a new method addContractConnection that you can call to add a function access key to an additional contract and store it locally.

For the particular issue for NEAR DevHub the idea is then to create the access key for the devhub contract when you submit something for the first time, and then reuse that access keys for later calls. This way, the user could also authenticate with other contracts on demand.

cc @ailisp @frol

[petersalomonsen]

See a proof of concept demo video here ( for the wallet-selector guestbook ):

https://www.youtube.com/watch?v=ocZKP2-Lxes

[ailisp]

@petersalomonsen the demo is very cool! I wonder how can we invoke wallet.addContractConnection from the DevHub widget, since there is no BOS api to access wallet directly

[petersalomonsen]

@petersalomonsen the demo is very cool! I wonder how can we invoke wallet.addContractConnection from the DevHub widget, since there is no BOS api to access wallet directly

@ailisp thanks, and actually you don't need to invoke that from the DevHub widget. This should be handled by the nearsocial viewer ( or maybe VM ) so that it detects if there's a wallet redirection, and then offers to add a function access key for that contract. Here's an example of how I've added this to the viewer for my PoC with the DevHub widget: https://github.com/NearSocial/viewer/pull/189/files

And this is also what's used in the demo you can see here: https://youtu.be/DVoZK5CJ2uE

[petarvujovic98]

What is the plan for this feature moving forward? Any timeline estimates or prediction of when it could be available?

[kujtimprenkuSQA]

What is the plan for this feature moving forward? Any timeline estimates or prediction of when it could be available?

The initial work for adding the signInMulti into the wallet-selector has been done in this PR, but to address the comment left here #811 (comment) there was a need to make some additional changes #847 that would be breaking changes in wallet-selector.

We still need a review from Pagoda and further discuss this implementation before it's merged.

As mentioned in the above comments the currently available keystores will have to catch up in order to support multiple keys per account near/near-api-js#1153 there was some work done related to it: near/near-api-js#1163