Allow multiple receiver_id for FunctionCallPermission struct

[nujabes403]

Near Protocol provides a great user experience through the use of FunctionCall Keys for signing transactions. With this feature, it is possible to log in to a dApp site using only the Function Call Key, without the need for a Full Access Key, making it more convenient for users.

However, most dApps are composed of multiple contracts, and this can lead to inconvenience for users who need to sign transactions with multiple Function Call Keys. For example, Ref Finance requires at least two Function Call Keys for the Ref-Exchange contract and the Ref-Farming contract. This can negatively impact the user experience.

Let's consider a specific gaming dApp composed of several contracts such as an "Auction Contract", "Character Movement and Attack Contract", and "Item Enhancement Contract". If we can create a single FunctionCall Key that can sign functions of the "Auction", "Movement", "Attack", and "Item Enhancement" contracts, we could provide a very convenient user experience by allowing users to access the game with just one Function Call Key.

Therefore, I propose changing the type of receiver_id in the FunctionCallPermission struct from String to Vec to improve the user experience.

cf) method_names may need to be updated to a 2D array type as well.

[mfornet]

Is it possible to add two keys in a single batched tx? That could solve the UX problem, or is there any issue beyond the first step of adding the keys?

[nujabes403]

@mfornet
Yes, it is possible to add two keys in a single batched tx.

However, I believe there is a potential UX problem in having to issue multiple Function Call keys just to use a single service.

In my opinion, current Near wallets that only allow logging in with Full Access Keys should also support logging in with Function Call keys.

However, even if Function Call keys are supported for logging in, using multiple Function Call keys to access a single service could still result in poor UX.

[bowenwang1996]

@mfornet while you can add two keys in one transaction, you cannot issue actions from both keys in one transaction as one transaction must be signed by a single key. At the same time, I am not sure how much a problem that actually is because even if we allow one key to sign both actions, still two receipts will be generated and it doesn't really provide any synchronicity guarantees. At the same time, my understanding is that function call access keys are usually held by the app, not the user, so that the app can sign on user's behalf. In that case, there doesn't seem to be a big difference whether one transaction or two transactions are issued. @nujabes403 could you elaborate on the difference? Thanks!

[nujabes403]

@bowenwang1996
Thank you for your comment, Bowen. You are right that Function Call keys are typically owned by apps rather than users in the current use case. However, the scenario I was assuming is one where users directly hold Function Call keys to use an app.

Currently, regardless of which wallet app is used, users are required to log in using their Full Access key. For example, even if users has a Function Call key for Ref finance's ref-exchange, users still need to enter their passphrase to log in using their Full Access key through wallets like Near Web Wallet.

To explain in more detail, there are two suggestions that I propose in this discussion:

1. Enable wallet apps to support logging in to Near's dapps using Function Call keys.

2. Once 1) is implemented, it would be inconvenient if the receiver_id of a Function Call key is limited to only one. For example, to use Ref finance, users need two Function Call keys: one for the ref-exchange contract and another for the ref-farming contract. In this case, users would need to log in with two keys on the same site. While having two keys is manageable, it could become very inconvenient if a game dapp is composed of five contracts and the target contract of a Function Call key is limited to only one.
   I hope this explanation clarifies my point.

[bowenwang1996]

@nujabes403 thanks for your clarification. However, I still don't quite understand the use case. What does a user gain by holding a function call access key themselves and logging into a wallet with that key?

[nujabes403]

@bowenwang1996

Ok, Bowen!

Here are a few scenarios that could occur:

1. (Security aspect) When a user tries to use a dapp on a PC that is not their own.
   If the user logs in via the Near web wallet with a Full Access key, it will be stored in the browser's local storage. If the user forgets to clear the data, it could be vulnerable to hacking attempts.

2. (Key usage aspect) When a user wants to allow a third party to use the dapp on their behalf.
   The user can log in with a Function Key that is only able to use certain functions of a game contract, such as moving or attacking.

3. (Prepaid gas usage aspect) According to Near docs, there is a concept of prepaid gas that allows users to use a dapp even if they do not have an account, using a Function call key. This concept allows users to use dapps without knowing about keys, but in some cases, dapps might give the Function call key directly to the user for use in the future. In this case, having the ability to log in with a Function call key would be quite useful. (https://docs.near.org/concepts/basics/transactions/gas#what-about-prepaid-gas)