Open heycorwin opened 3 years ago
@jimmy3dita Would you be able to assist in filling in any gaps here?
I think we can abstract this feature as "an alert for every action that requires the wallet private key to be completed".
The actions are:
Out of scope >> will explain below:
This is straightforward, we need to display amount and recipient
Any confirmation should enable the user to know:
deposit_and_stake
but not send tokens)In my opinion, this class of authorizations requires a lot of adversarial thinking and find a high-level security abstraction. Ideally, the user should be able to understand, in less than one second, if this key is able to:
up to x funds
with a confirmationStaking and unstaking, adding 2FA, changing 2FA, transferring fungible and non-fungible tokens are all call methods
that require the private key.
Any confirmation should enable the user to know:
call
being done (e.g. deposit_and_stake
or add_request_and_confirm
)amount
and is expressed in yocto)In this case, we need some key-value table (I would love to see it on a public document, so the community can contribute) such that:
stake
would simply be "please confirm you want to stake %amount% to %recipient% with the method stake
"stake
has the argument '{"amount": "120000000000000000000000000000"}'
>> so we should parse this amount accordinglyadd_request_and_confirm
contains within itself another call and another payload. E.g. the transfer of 1 NEAR via 2FA would be like:
{
"request": {
"receiver_id": "quato.near",
"actions": [
{
"type": "Transfer",
"amount": "1000000000000000000000000",
"deposit": "1000000000000000000000000"
}
]
}
}
To make things a bit worse, the unstake
would look like:
{
"request": {
"receiver_id": "08investinwomen_runbybisontrails.poolv1.near",
"actions": [
{
"type": "FunctionCall",
"gas": "125000000000000",
"method_name": "unstake",
"args": "eyJhbW91bnQiOiIxMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwIn0=",
"amount": "0",
"deposit": "0"
}
]
}
}
The args eyJhbW91bnQiOiIxMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwIn0=
is the Base64 encoded string for {"amount":"1000000000000000000000000"}
, but it can be more complex if it is a batch transaction, or contains Rainbow Bridge proofs.
Stake This is a legacy method that allowed a wallet owner to stake on its own behalf and is similar to sending tokens. Now everything is going through staking pools, so this specific command should be disabled from happening via near-api-js or at least ignored.
Create account & Delete Account These are mostly handled by the backend, we may want in the future to enable power-users to access these methods, but I don't really see the value to have it in the wallet.
We all agree that NEAR Wallet team cannot maintain an (exponentially growing) table with smart contract call methods and their arguments. The good news is that we need this abstraction across all user-facing NEAR products and potentially the entire ecosystem. So far, I've seen the need to understand transactions on:
So, while the confirmation UX urgently needs improvements, I see the opportunity to launch a cross-functional work that may structurally solve the problem, and use some "collective intelligence" to properly represent this very heterogeneous information. We already partially discussed (the Widget concept, and the "PR-able" list of contracts and tokens).
Abstract this information on a new repository (or an easy-to-contribute-to directory in the wallet repo), and add the first items ourselves - starting from your actions above, and then pushing NEAR and external developers to review the content.
Problem Summary
There are a number of instances when a user performs a transaction, where they are required to confirm the transaction. Additionally, users with 2FA receive messages detailing the transaction and are required to use the code provided in order to confirm. Once a transaction is processed, success states are used to confirm that the transaction has been processed successfully. While all of these exist currently, their utility is low. Each of these screens and emails either provide little context and information about the transaction (eg gas), hide it unnecessarily, or lack a certain degree of polish in the language and phrasing that is used.
Proposed Solution
It would be worth attacking all of these instances in one fell swoop. We have an opportunity to improve the consistency across all instances of transactions confirmation messaging and success states. First, we should identify every instance, and then determine what transaction metadata is most useful for the user for each (could perform some light research to inform this). We should then craft a consistent UI to display this metadata for each instance of user authorization and success in the wallet, as well as fine-tune our 2FA messaging templates.
Dependencies
Identify all instances of Transaction Confirmations
Referenced in