# NEAR Wallet Selector Flows

## Context

We analysed NEAR protocol and tested out their SDK for a better understanding of the nuances of the protocol. Part of development:
- Near wallet selector
- *.near.web3auth.io

## Flows

Below are some of the proposed flow diagrams after integrating web3auth in NEAR wallet selector:

*(in all the below flows wallet app is finally responsible to connect with Dapp and sign transactions, also assuming wallet support injecting keys)*

### Flow 1


Pros:
- Don't have to do account funding. Its offloaded to wallet
- No separate full access keys generated for wallets (Security against 1/2)
- Once the key is injected to the wallet app, the wallet selector does not have any role in transaction signing etc.

Cons:
- Users won't get a named account and have to deal with random string account ID’s.
- Can be solved if dapps force/pay for explicit account creation
- Wallets could take users via explicit account ID creation flows which might again prompt the user to write down and backup the seed phrase, which defies the whole purpose of web3auth integration.
- This can be solved using implicit -> explicit account creation (same seed)
- We are assuming that the wallet application will allow a key injection flow for another window.

Wallet implementation:
- Step 6: Allow `importKeys` API. This can be implemented in many way, such as, encrypted server communication (ECDH), broadcast channel APIs, chrome APIs for extensions, redirect flows for web wallets etc.
- Step 8: Connection: This is trivial for web and extension wallets. For native wallets, we can use wallet connect.

### Flow 2


This flow is very similar to flow 1 but, here a new "full access key" is generated and injected into the wallet. We don't deal with any explicit account IDs here as well.

Pros:
- Each wallet app gets its own unique access key, so the web3auth could potentially have a dashboard in future to delete the access key of a particular wallet. (In case of theft)
- Since wallet apps have their unique access keys, if needed the user can check which wallet application was used to sign a particular transaction.

Cons:
- No named accounts.
- Needs a funding source to prime the implicit account with enough gas to create access keys.
- This could be web3auth/Near foundation
- Access key still is very powerful and wallet apps can still delete the original key backup by web3auth.
- Explore if threshold deletion can be added ??

Wallet implementation:
- Step 8: Allow `importKeys` API. This can be implemented in many way, such as, encrypted server communication (ECDH), broadcast channel APIs, chrome APIs for extensions, redirect flows for web wallets etc.
- Step 10: Connection: This is trivial for web and extension wallets. For native wallets, we can use wallet connect.

### Flow 3


Similar to flow 1

This flow forces users to choose an AccountID (eg: username.near) in the signup flow itself. Same seed from implicit account is used to create a named account.

Sign In flow will reconstruct the key from openlogin and inject the key for the accountID into wallets.

Pros:
- Least friction to the user, he gets a named account backed up by web3auth.
- User are not exposed to hex account addresses.

Cons:
- Requires a funding source.
- Same priv key across all wallet apps.

Wallet implementation:
- Step 9: Allow `importKeys` API. This can be implemented in many way, such as, encrypted server communication (ECDH), broadcast channel APIs, chrome APIs for extensions, redirect flows for web wallets etc.
- Step 11: Connection: This is trivial for web and extension wallets. For native wallets, we can use wallet connect.

### Flow 4


This one is very similar to the 3rd flow and the only difference is individual access keys are generated and injected into wallet apps. Again the user will get access to the named account he created in the signup flow across all the connected wallets. But the difference is that the wallet selector will inject a newly generated full access key to the wallet app the user selects.

Pros:
- All the pros of flow 3
- And pros of flow 2

Cons:
- Needs funding.
- Access key creation burns near token.

Wallet implementation:
- Step 10: Allow `importKeys` API. This can be implemented in many way, such as, encrypted server communication (ECDH), broadcast channel APIs, chrome APIs for extensions, redirect flows for web wallets etc.
- Step 12: Connection: This is trivial for web and extension wallets. For native wallets, we can use wallet connect.

### Flow 5


In this flow each individual wallet need to integrate tkey or openlogin in their code and allow the signup and signin flow within their UI.

Pros:
- Tried and tested formula.

Cons:
- Every wallet needs to integrate Web3Auth sdk.
- Too much heavy lifting required for wallets.
- Web3Auth is not the sole entry point here.
- Since wallets need to maintain unique openlogin clientId's each connected wallet gets a different NEAR account.
- Entry point is not from DApp instead users should create account first on wallet and connect DApps.

## What wallets need to do

For flows 1 - 4 :

- Wallets should support/ allow importing keys.
- We could build a secured communication channel between Dapps and wallets that integrate near wallet selector sdk.

For flow 5 :

- Wallets should integrate web3auth sdk.

## Proposal for Wallet and Dapp Connection


We can consider including an encrypted communication channel between DApp and wallet via a secured bridge server. DApp and wallet will use a shared symmetric key for secure communication. Connection URL and shared key can be exchanged via a QR code scan (in the case of browser DApp native wallet connection) or via direct injection if DApp and wallet are browser-based.

## Other Considerations & Observations

- Flows 1 to 4 allows to keep DApp as the point of entry to account creation and also lets have same account across all the wallets.
- In the flow were ledger is used to backup the near wallet, ledger device generates the original keypair and the web wallet receives function call key signed by ledger.
- It is possible to delete all keys of explicit and implicit accounts. Original key can also be deleted with a full access key, which allow wallets to potentially delete the key secured by web3auth.
- It is possible to register accountID against an already active implicit account.
- NEAR team is okay with considering wallet apps as trustworthy and secure.

## Questions
- It is technically possible to use the same key pair of an implicit account to create an explicit account. NEAR mainnet wallet uses a different key for an explicit account and lets the user write down the seed phrase for it. This leaves the user with 2 seed phrases to secure. Why not use the original keys?

- Can we use near drop in flow 3 and 4 ? https://near.org/blog/send-near-to-anyone-with-near-drops/