near / near-wallet

Web wallet for NEAR Protocol which stores keys in browser's localStorage

NEAR Wallet

This is in-browser web-based wallet for working with NEAR accounts. This wallet stores account keys in open text using the localStorage on user's machine.

WARNING: This wallet shouldn't be used as the only signer for high-value accounts. Make sure to use hardware wallet when substantial amount of NEAR tokens is involved.

PACKAGES

e2e-tests

Test suite for verifying core use cases and user flow are functional in the UI

frontend

Wallet frontend (React/Redux app).

near-wallet's Issues

Authorize specific transfer transaction in app

As a user of an app where the app is requesting to initiate a transfer of tokens operation, I want to be able to examine and approve this transaction.

Acceptance Criteria

• App can request token transfer transaction
• Transfer debits and credits tokens properly
• Wallet redirects to approval flow
• Flow redirects back to app when complete
• Mobile views ok
• Sad path: User denies request
• Error handling: App formats request improperly
• Tested

Assets

• Mockup: cc @jakestutzman
• TODO: Figure out display of gas fees
• TODO: Figure out interaction of user with gas fees
• TODO: Figure out display of waiting statuses for inclusion in block -- eg sent, received (in mempool), included, waiting (congestion), etc.

NOTES

"Log out" of the application from within the application

Story

As a user who has a NEAR wallet and has previously used it to log in to a third-party app and is now currently using that third-party app, I want to be able to de-authorize (log out from) that application so it no longer is using my information.

See NOTES below for important discussion about specific states and intent of this.

Acceptance Criteria TODO

• AC1
• AC2
• Mobile ok
• Tested

Assets

• Mockup: TODO after states are specifically figured out.

NOTES

Re: Intent

The idea of this is to provide a standard interface and UI pattern for apps which are authorized by the NEAR wallet to interact with those permissions. We'll use this in our sample apps and let developers adopt that pattern too.

Re: States

We still do get into the question of what "log out" means because in this case, de-authorizing the app means the app can't actually access any of your account even when you disappear. So it's closer to "delete my account on this app" than "log out from this app".

It's not exactly the same as "delete my account" because the app could still keep all your information waiting for you when you re-link your account.

So for clarity it's actually important to highlight always the difference between the states and it actually brings up the idea of "application-specific logins".

1. "Log out of application" (For example, if you are lending your computer to your kid and don't want your trading app open but do want a game open): Just removes that browser's login session from the application but keeps everything else behind the scenes.

2. "de-link/de-authorize application" (you want to remove that application's access to your account on ALL browser sessions now and forever): Revokes any access the application has to your NEAR account and logs you out of your current browser session with that application.

3. "delete account on application" (You want to remove the app's access AND don't ever intend to return to it): This does same as de-link/de-authorize but also explicitly asks the application to remove your account state (otherwise they may keep your account state around and expect you to re-link it).

Transaction progress states

Story

As a user who has just clicked "confirm" to authorize a transaction (either inside an app or sending in wallet), I want to know what the status of that transaction is until it's final so I can understand why it's taking so long.

This is especially important for most naive UI's which will be implemented synchronously and thus have the user staring at a waiting screen for some period of time.

See NOTES below for discussion.

Acceptance Criteria

• TODO: After fleshing out the exact states that we can/should report
• Mobile ok
• Tested

Assets

• Mockup:

NOTES

• When we send money, what waiting states do we actually have access to (now or possible in the future)? For example:

• Transaction sent
• Transaction received/acknowledged by the network (a node)
• Transaction in block mempool (or equivalent)
• Transaction executed in block 12345 [link]
• Transaction was success with return_value_or_state_change or failure for reason.

This is important so we can provide users with clarity around what they're actually waiting for while we're making them wait for things.

Also important that some apps have different finality than others, so their UIs might prefer to implement immediate finality or they might wait until X blocks (or other criteria) passes before showing the user a confirmation. That's fine -- let's expose the raw blockchain stuff to start with and assume immediate finality and if the app doesn't want this, they can use those same hooks and modify the UI on top to wait a bit longer.

This is inspired by how AJAX has a clear 5-step state machine that defines its status and allows developers to build waiting icons and UI notifications against those states.

It sounds like there are RPC endpoints for transaction status so this can be done via polling. Can it be done via the nodes sending something back to avoid constant read pings?

Complication: For transactions that generate receipts for later, what is finality anyway? How do we model states for something that's inherently unclear when it will end (how many calls deep it will take, and they're async)?

Visual inspiration

These are dumb loading bars since they tend to only have a "% complete" but are the basic idea: https://www.downgraf.com/inspiration/25-beautiful-loading-bar-design-examples-gif-animated/

What I imagine the naive implementation is something like a list of grayed-out checkboxes with state descriptions that get highlighted then checked off with a green checkmark in realtime as the transaction propagates through the various states so the user can see it happening. Then it disappears to the confirmation screen when all is well. But that's ultimately @jake 's realm

Create wallet SDK

• Upgrade login.js to wallet-sdk.js
• Remove jQuery dependency from the sdk
• Add iFrame messaging capability
• Remove hardcoded URLs
• Fix near madness example and test

Contract Metadata

Story

As a wallet owner who's logged in and is linking an application to my account, I want to see enough information about that application so I can determine if I should trust it or not.

Acceptance Criteria

• Displays application name, short description, URL and image as per mockup on app permission screens.
• Properly displays this information across application index pages and other views where applications are listed
• NEP created for this
• Mobile ok
• Tested

Assets

• Mockup:

NOTES

Validator Staking

Dealing with staking as a validator.
Separately tracking delegation in #521

User stories

• Validator wants to send staking transaction for a given public key
• Validator wants to send unstaking transaction
• Validator wants to accept delegations (by deploying delegation contract and configuring it with %)

Log out of wallet

I want to be able to log out of the wallet locally (eg if storage was nuked and it no longer actually exists on the blockchain side) and then either create a new account or log into an existing one.

If account does not exist we should offer to reset it

Currently when go to wallet directly or if I try to login with NEAR from an app, and my accounts is not present I get hanging window:

We do have error coming back indicating that account is missing. At this point we can either offer or automatically reset the local storage and proceed to create new account / choose from other accounts that may be present.

(And yes, ideally we don't have this situation on official testnet, but remember that we will have other testnets and ppl will reset them)

Delink individual app access from Authorized Apps page

As an end-user who has linked an app with my wallet account and is on the Authorized Apps page, I want to de-authorize that app so I can rest easy that they no longer have access to my data.

Acceptance Criteria

• Select a single Authorized App on the Authorized Apps page to open details
• Mobile works and matches mobile view
• Includes same placeholder "Authorized To" text as the authorization flow shows the user initially when authorizing that application
• Does NOT include "Recent Transactions" tab
• Includes placeholder images for apps (we haven't wired this up yet)
• Does NOT include the website for the app (haven't wired this up yet)

Assets

NOTE: waiting for updated lite mockup from Jake as of 5/25/19 to show how the frontend should look.

• Full mockup (shows more features than currently building) https://projects.invisionapp.com/share/Y5QIVUGTVER#/screens/356310180
• Expanded view (shows more features than currently building): https://projects.invisionapp.com/share/Y5QIVUGTVER#/screens/356310179
• Pixel perfect Zeplin files at https://app.zeplin.io/project/5c801b27f9e6e211c76f94f2/screen/5cb0a9fda8666961127d6169

NOTES

View authorized applications list

As an end-user who has linked several apps with my wallet account, I want to see which apps have permissions currently linked to my account so I can begin to manage them.

Acceptance Criteria

• The Authorized Apps page
• Mobile view works
• ??? The "Authorized X hrs ago" indication for each app
• ??? Sorting selector by "Recently Added" or "Name"
• does NOT include the "Search Apps" form

Assets

• Full mockup (shows more features than currently building) https://projects.invisionapp.com/share/Y5QIVUGTVER#/screens/356310180
• Expanded view (shows more features than currently building): https://projects.invisionapp.com/share/Y5QIVUGTVER#/screens/356310179
• Pixel perfect Zeplin files at https://app.zeplin.io/project/5c801b27f9e6e211c76f94f2/screen/5cb0a9fda8666961127d6169

NOTES

(notes from sprint planning meeting, verbatim) "NEARLIB part needs a wrapper to call the RPC. Rust RPC is there. Do we want the keys themselves or the struct? Struct. That needs to change."

Send Money

Everything around sending tokens to other users, whether from within the wallet or called via external means.

Recover account using phone-based recovery

As a user who has lost my keys or is using a new device, I want to recover my account using my telephone so I can continue along my merry way.

Acceptance Criteria

• After creating account in one browser, user can activate account on new browser using phone.
• [-] Human-readable error messages >> Pulled out into Issue #89
• Works in Safari
• Works on android
• Works on iOS
• Tested

Mockups

TODO @jakestutzman

Notes

what if user doesn't know their username either? Should they be able to look it up using their recovery phone?
what if user has linked multiple accounts to their phone number?

Storage fees in wallet

This is deeper than meets the eye and includes everything related to dealing with storage fees.

• Displaying storage fees in the wallet in a way that users clearly understand how they work and why exactly they are being charged.
• Handling what happens when the user's account doesn't have sufficient tokens to pay for their storage -- how do we show the account has been "sleeped" and then recover it later once more tokens have been added?

Warning on create account - recover account

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
in CreateAccount (created by Context.Consumer)
in Connect(CreateAccount) (created by Context.Consumer)

Validate form after the TX is sent

Also set amount to 0 and username to empty field

Error handling for phone-based key recovery

Story

UH OH TODO -- doing this live so not doing this...
As a USER who PRECONDITIONS, I want to DO_THING so I can ACCOMPLISH_GOAL.

Acceptance Criteria

• Handles if there is no account linked to a phone number (Can't remember... is it better to say "no account or phone number by that name" or to specifically say if it's the account ID or the phone number that failed?)
• Error message displayed for expired code
• Button to re-send code on the code entry page (for expired codes)

Assets

• Mockup:

NOTES

Wallet should be able to authorize some TX without popup

Fiat-to-Crypto Onramp/Offramp

Everything to do with integrating with onramps which provide access to fiat-to-crypto tranfers, eg Wyre and Simplex

Authorize page - layout bug - when screen size is limited, buttons disappear

see sreenshot

Google APIs don't work in China

via @ilblackdragon :
On GuestBook/Wallet frontend somehow jquery from googleapis was added (T https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js net::ERR_CONNECTION_RESET) which doesn't work in China.
It wasn't there a week ago - can we not use google CDN?
or this is google analytics?
it's not loading broke all JS on the page - so "Login with Wallet" didn't work at the demo 😦

Unable to send tokens

I get this error when I try to send tokens to another account.

Error! BadRequestError: transaction not signed with a public key of originator

Screenshot:

Phone-based key recovery

Set up phone-based key recovery

As an end-user who is setting up my account for the first time, I want to link my phone number to my account so I can later recover my account on a new session by using my phone.

Acceptance Criteria

• User can set up phone number during account setup flow
• Works on mobile
• Handles invalid phone number format (client-side)
• Handles if there is no account linked to a phone number (Can't remember... is it better to say "no account or phone number by that name" or to specifically say if it's the account ID or the phone number that failed?)
• Error message displayed for expired code
• Button to re-send code on the code entry page (for expired codes)
• Link / button to add phone number in account Profile page cc @jakestutzman
• Link / button to remove linked phone number in account Profile page cc @jakestutzman

Assets

• Mockup: https://projects.invisionapp.com/share/9ES2D82U8GB#/screens/363859405

NOTES

authorize app flow: navigation is not going to the right page after recover page

to repro:

• clear browser storage
• http://localhost:3000/login/?title=NEAR+Guest+Book&contract_id=studio-v7u2bhig5&success_url=https%3A%2F%2Fapp.near.ai%2Fv7u2bhig5%2F&failure_url=https%3A%2F%2Fapp.near.ai%2Fv7u2bhig5%2F&app_url=https%3A%2F%2Fapp.near.ai
• go through create account
• "not now" on recover
  Expected to go to authorize page. Actual behavior: goes to dashboard

Wallet does not work with near-ops

To reproduce:

• Get the recent version of near-ops:

git clone https://github.com/nearprotocol/near-ops

• Start the node (It will take ~10-20 minutes since we are running for the first time from a clean folder):

./run_local_dev.sh

• Open studio http://localhost and make sure the Hello World contract is working (it makes sure the fiddle api has started which takes long time).
• Open "Example of NEAR Wallet Integration" and try running it. Get the following error message:
  https://www.dropbox.com/s/ac0r8dgnesi1txo/Screenshot%202019-06-05%2009.49.17.png?dl=0

Multi Token Support

Support additional token types on NEAR (eg ERC-20-style), NFTs and wrapped tokens from other chains.

Check that account doesn't exist before creating a new account

Would be nice to validate this name when you finished typing it (after 250ms with timer reset).

Extract reusable components to avoid copy-pasting styles, etc

Buttons - contain all buttons with various types:

• Create Account - form button

• Recover Account - form button

• Recover Account - skip this step

• Set Recovery Info - form button

• Authorized Apps empty list

• Dashboard - Send Money

• Dashboard - View All

• Login - Allow

• Login - Deny

• Send Money - Cancel Transfer

• Send Money - form button

• Send Money - Confirm & Send

• Send Money - Go back

• Main Menu - Create Account on mobile and desktop

Page Container - contain the top and bottom part of the page container:

• Authorized Apps

• Contacts

• Dashboard

• Profile

• Send Money

AccountId Input - form input for accountId, with account availability check and validation:

• Create Account

• Recover Account

• Send Money

Amount Input - form input for a token amount, with amount validation:

• Send Money

Account Form Container - contain the top and bottom part of the account form container:

• Create Account

• Recover Account

• Set Recovery

Account Form Section - contain left and right section of form container:

• Create Account

• Recover Account

• Set Recovery

Pagination Sub Box - contain a box that appears on list element click:

• Contacts

• Authorized Apps

Account Image - round image in various sizes and default icon:

• Dashboard

• Authorized Apps - list

• Authorized Apps - sub box

• Contacts list

• Contacts sub box

• Send Money

• Login

• Profile

• Main menu

End to end tests for critical user journeys

• Create Account
• Approve App-specific Key
• Send Money
• Recover Account

Send tokens to user

As a user logged into my account on the web wallet, I want to send 100 tokens to another existing user so I can pay them back for that Bitcoin Pizza.

Acceptance Criteria

• Can send tokens between accounts that exist
• Proper error handling and user-informing for cases where account doesn't exist
• Updates balance of recipient user immediately upon refreshing their browser
• ??? Include "Add a note..." field?

Assets

• Sparse mockup: https://projects.invisionapp.com/share/9ES2D82U8GB#/screens/363859416
• Full mockup (includes extra features): https://projects.invisionapp.com/share/Y5QIVUGTVER#/screens/362044982

Notes

Improve UI of redirects

• When wallet is empty and need an account
• After creating a new account

Add ability to open a wallet in a popup instead of a full redirect

Integrate with NearPlace

Multisig / guardian-based account recovery

Placeholder for implementing multisig account recovery, for example if you lose your key and need to have your sister and uncle provide theirs to allow you to do an account reset. This is actually quite complicated.

What is the MVP of "guardians"? Having a simple X of Y authorized account recovery via other blockchain accounts which serve as your guardians?

Basic flows:

• Register a guardian
• De-register a guardian (noting how this might break multisig schemes if you fall below a threshold)
• Utilize guardians
• Change guardian details

Once the basic infra is in place, we can start substituting in other types of guardians. Presumably there is a reasonably standardized way to plug in a new guardian type and set up the registration process for this guardian.

App Authorization / Permissions

Everything having to do with an application requesting access to elements of the user's account and how permissions for those applications are handled and displayed.

Can we have module isolation model for wallet app?

Full wallet app might be hard to audit. Given that all dependencies can potentially have vulnerabilities injected, it's nice if we can isolate signer (and key storage) from other wallet app components.

Placeholder: Spec out application access permissions

We need a standardized way to handle how applications are granted permissions to perform actions on behalf of users (this also will affect how one-off transactions are displayed). For example, there should be a structured difference between an application being able to transfer tokens on your behalf and make writes to an application on your behalf. But what if those writes include the ability to transfer NFTs or something else?

The user needs to know explicitly what's going on when they are granting access to something to an application and should be able to clearly modify those permissions after the fact.

Some permissions worth thinking about including:

• transfer SPECIFIC_QUANTITY just ONE_TIME of NEAR tokens
• transfer SPECIFIC_QUANTITY every N_TIME_UNITS of NEAR tokens
• run SPECIFIC_METHOD which says "METHOD_META_DESCRIPTION" N_TIMES in N_TIME_UNITS
• ... but that method may want to specify other parameters. For example, let's say the method creator actually wants to allow you to pass certain more granular parameters which change the method's behavior... is there a way for them to metaprogram the access?

How do we make sure that developers can't maliciously request access? What happens if that method actually calls out to other contracts in ways the app never intended? How do we protect downstream methods from accessing elements of the user's account, essentially by only white labeling areas of a user's account that can be touched by it?

cc @vgrichina

add support for configuring RPC address

Consolidate request status / error handling

We still have some components using errorMessage / successMessage flags to manage errors.

I suggest we move to more flexible architecture: https://github.com/nearprotocol/near-wallet/wiki/High-level-app-architecture#async-request-dataflow-overview
This would allow handling different error reasons, etc. It also allows automatically handling errors for promises dispatched in Redux.

[Potential Pull] add verify/sign, encrypt/decrypt, generateSharedSecret

I am willing to put this through but first posting here before starting. The idea is to take more from tweetnacl to include converting ed25519 to a Curve25519 keypair.

Adding verify/sign of a uint8array
Adding encrypt/decrypt of uint8array using Curve25519 keypair generated above
Adding generateSharedSecret using wallets priv key + another account name (or pubkey)

Improve username input

Currently username input is confusing cause it allows you to enter invalid characters and then complains. Should instead normalize automatically to lower case and ignore invalid characters.

Should also have proper hints for mobile like what keyboard to use, disable autocorrect, etc

Hardware Wallet Integration

Overview

To provide a high level of security, without the need for a third party custodian, we should provide support for hardware wallets (e.g. Ledger).

The user stories below are listed from highest priority to lowest.

User Stories

• As a user, I want to create an account in the NEAR Wallet while storing my private key on a hardware wallet, so I can create a secure, self-custodied account.
• As a user, I want to open existing account(s) in NEAR Wallet that I have access key on a hardware wallet.
• As a user, I want to sign a transaction in the Wallet using my hardware wallet-secured account, so I can use apps that may not have native hardware-wallet support.
• As a user, I want to transfer tokens using the Wallet with my hardware wallet-secured account, so I can move assets without using the CLI (@vgrichina unless we can do this in the Ledger app?) .
• As a user, I want to add and remove keys from my hardware wallet secured-account, so I can use multiple devices, and create backup methods for my hardware wallet.
• As a user, I want to view and interact with my hardware-wallet secured account in the Wallet, so I can learn more about my current asset balances and view recent activity.

Integrate with MVC TODO

test issue

1. testing
2. Testing again

• foo
• bar
• [ x ] bar
• bar
• [] foo

[Safari] Verify and switch to use cookies instead of localStorage

It seems safari properly respects default privacy settings only with cookies. Currently safari still sandboxes iframes of the wallet for localStorage even if have visited the website before this. But cookies seems to be passed through to the iframe. So we may consider switching to cookie storage on wallet side. Cookies will only be visible to the wallet.nearprotocol.com.
The issue is the security of the data will be accessible to the server-side. Need to think more about this, but one option is to encrypt keys stored in cookies with the application token. So whenever wallet is accessed by the application, it always provides the token. We can decrypt cookies with this token and sign transaction. In this case, if we never expose token to the server-side, it would be somewhat secure, while still not ideal.

Extract `process.env` into `config.js`

Wallet is a static so all process.env calls are only relevant during npm run build. Since docker image will not run npn run build upon each start but instead will run it only when it is created env variables will not allow us to control the static content. Instead we should be using config.js similarly to how studio does it and have all parameters there.

Governance / Voting

Everything to do with participating in on-chain governance and voting

Display amount with decimal point for 10^18

Currently 1 NEAR is considered a 10^18 atto-NEARs. We should display it that way, instead of displaying in atto-NEARs.

no favicon

Bug: if the rpc to view_account fails, wallet says that account name is available

Expected behavior is to show an error.