This is to outline the issues and potential ideas how to address current issue with wallet usage from applications.
Currently there are two interesting issues with using wallet in apps on NEAR:
- Almost all application code just directly links to wallet.near.org
- Application level wallet usage code is split between near-api-js and near-wallet codebases. Many general pieces of code must be copy-pasted (like using Ledger in Web, parsing lockup state and more)
Direct linkage of specific version of web wallet means, that other wallets are hard to impossible to use. There are already options like 2 chrome extensions, mobile wallets and more.
To be more clear, let’s split wallet functionality into few different things:
- Primary key management: this is where full access or similar is stored, providing recovery and other ways
- App key management: managing app specific key scoped to limited set of actions
- Tx signing and routing: given a transaction, signing it and sending it into the network, either directly or via relayers (Using NEAR with Ethereum wallets).
Application devs if they want to support more things primary key management outside of NEAR wallet need to implement their own additional management.
App key management implementation in near-api-js is also pretty limited and missing various functionality.
We also have multiple different ways to route transactions to the network and probably more is coming.
Proposed solution to define a “Wallet SDK” interface which provides an abstractions for the wallet related usage. Implemented in the JS or other language libraries.
First, it is able to ask user which wallet they want to use. The registry of wallets can be some form of smart contract registry. To start managed more centrally via NF but over time will opened up to members of relevant advisory boards.
Hence when user presses Login, there is a menu to select which wallet they want to use (similar exists in Ethereum right now). This menu both can be done on application side or when user gets sent to “wallet.near.org” (I like matrix.org invite selector for this).
Of cause, if user already selected something, that wallet should be used across all the applications by default. While there should be also an option to change (some users will use multiple wallets – especially developers).
There is an important part, which is what Wallet Connect is trying to define - an interface for signing transactions outside of direct HTTPS flow which is impossible with many wallets. Working with their team is important here to have the same protocol for exchanging the relevant information (request id, metadata, etc).
Wallet SDK contains our app level code for managing “App key management”.
This is where the code lives to identify if transaction is under permissions or primary key management must be called. Any additional logic, like managing allowances and more can live here as well.
Additionally, Wallet SDK would contain any relevant relayer code for routing transactions that are meta-signed instead of directly signed. For example this is relevant for Using NEAR with Ethereum wallets and other related work. This is also where RPC discovery should be happening (On-chain discovery service).
Curious what do you think?