Giter Site home page Giter Site logo

nano-wallet's Introduction

LSIO Nano Wallet

LinuxServer Nano Wallet

Demo

To try this wallet please access Discord and use the #faucet channel to get funds. Those can be used on our public network:

https://wallet.linuxserver.io/#/nano.linuxserver.io

Intro

This project has some core goals that are very different from a conventional CryptoCurrency wallet:

  • Ability to hook into a user defined network
  • Interact with a raw Nano RPC endpoint without middleware
  • No live info feeds for transactions (websockets), data is loaded from remote statically and the user needs to manually refresh
  • Completely clientside and run in any web browser with no server requirements (even object storage)
  • No browser/disk local storage used
  • provide block explorer functionality with the clientside wallet and publically clickable links

With these goals there are some tradeoffs from a functionality standpoint. One of the biggest being the "near instant" concept of using the Nano protocol are not as instant here. A user needs to manually refresh and manually recieve transactions on their end. Generating your Proof of work using browser javascript will generally be slower than using natively compiled crypto libs. The user will need to enter their private key every time they access their wallet and conduct transactions.

With that said, these design concepts greatly reduce the barrier of entry to a user of your network. The end user can simply access a web page, generate a wallet, and be off and running after they are sent funds.

Hosted wallet endpoints

The source code for this project is built transparently and published to Github pages at the following endpoints:

The URL paths for public block exploration are in the following format:

We also provide Point of Sale like functionality using the following format:

The Point of sale view is designed around the concept that you will be actively receiving funds during a transaction, and pocketing them later from a secure backend/terminal. It can be accessed by anyone and does not require credentials. You set the amount and a QR tag is generated from that amount. Once the amount is paid by a user from their phone/device the delivered transaction to that specific wallet you will trigger a success notification and the total owed will be cleared for the next transaction. Using this model it is important to not use duplicate wallets across different terminals or endpoints or your transactions during the receive window will conflict. It is important to note that the same functionality is available from the Receive menu with an opened unlocked wallet.

If this wallet is forked from this source and published elsewhere or to your own Github pages endpoint as laid out in the Customisation section of this document you should use the following URL formats:

In general this URL format is self documenting from the wallet interface as all of the links will use these endpoints in new windows to provide shareable public links.

Live Nano network addresses

We will list here Live Nano RPC provies that we add and how to use them.

api.nanos.cc

Does not requires an API key to use

mynano.ninja

Requires an API key to use: https://mynano.ninja/auth/login#apikey

For users

We recommend end users looking to locally host this wallet themselves use the Docker container located here it is a simple nginx wrapper for the built code from this repository.

Run example:

docker run -d \
  --name=nano-wallet \
  -p 80:80 \
  --restart unless-stopped \
  linuxserver/nano-wallet

Then access http://localhost/#/YOUR_RPC_ENDPOINT .

This wallet was designed around the software stack described here, and specifically our Nano Node image with a firewall to allow default wallet RPC calls here.

Customisation

If you want to lock the wallet to a specific RPC server then go to src/stores/app/state.js and change changeaddress to false, the node will then be locked to the node details directly beneath (only change the settings node details not the main node details).

From there basic branding would be to modify the site title found in .env and swap out our QR code icon at /public/qr_logo.png and public/wallet_logo.png for the paper wallet, we have specifically made efforts to not brand this wallet to our codebase or organization to allow anyone with a public RPC endpoint to also host this wallet themselves and have their users use it as a wallet and block explorer.

Currently statically set RPC endpoints allowing users to simply access https://wallet.yourdomain.com and be off and transacting require that the block_count RPC action is whitelisted by your RPC servers, it is used on connect to ensure the RPC server is healthy. You can also optionally setup multiple RPC servers to fall back on in case of downtime by defining multiple in the src/stores/app/state.js array for node.

If you want to support scanning of NFC tags from your web wallet please note that because the Chrome support for Web NFC is currently in an experimental stage you will need to register an origin token here:

https://developers.chrome.com/origintrials/#/view_trial/236438980436951041

And set the token in .env to the one for your own Domain. Keep in mind this will only function on Andoid with Chrome on a device that supports NFC.

Hosting your forked repo from Github Pages

If you are planning on hosting this wallet on your domain pointed to your RPC servers, for transparency it is likely best to fork this repo and publish it using Github Pages . Here are the basic steps to follow to achieve that:

  1. Fork this repo into your namespace in Github
  2. In your repo under Actions click to enable actions on your fork
  3. In your repo main settings enable Github pages and set your custom domain
  4. Generate an API key following the instructions here, you will need to select the repo permissions
  5. Set this API key in your repo settings under Secrets as ACCESS_TOKEN this key is needed to publish changes to the gh-pages branch of your repo
  6. Push your customizations to your repo on the master branch, this should trigger a build of the site and push to the gh-pages branch using the logic located here
  7. When built the wallet will be available at the endpoint you defined pointed to your RPC servers given you have the DNS properly setup as described here

From here you can ingest upstream changes from this repo when needed and customize it to your needs while Github deploys your site on updates to their hosted CDN.

Building from source and development

The frontend framework for this project is vuejs below are the commands used to build this project from source and run a local development environment. We highly reccomending using vuejs-devtools locally to inspect and debug.

This project's core logic for performing Nano transactions uses nanocurrency-js please take time to review their calls along with general RPC interaction with a Nano node here.

Project setup

npm install

Compiles and hot-reloads for development

npm run serve

Compiles and minifies for production

npm run build

Lints and fixes files

npm run lint

Customize configuration

See Configuration Reference.

nano-wallet's People

Contributors

dependabot[bot] avatar joohansson avatar kodestar avatar nemchik avatar thelamer avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

kodestar joohansson junwei0117 wattcash lj020326 greticani hummans kimubach elieladelrom adamvallee isabella232 ogensogens megavillain ac1234567890

nano-wallet's Issues

Warning before logging out

Reddit request: Popup warning when you press logout button. This kind of indicate that you might not have saved your seed so I don't know. I'm fine with either.

Suggestion: Hidden title or console log with ledger cemented block count

During a spam attack or any problem with a Nano node it may lack behind in cemented blocks. That will cause problems for the wallet for example pending not showing up as they should. By displaying the cemented block count somewhere could be very useful in that scenario for troubleshooting because you can compare to a site like nanocrawler.cc or nanoticker.info to compare with other nodes. This is not for the normal user so it should be hidden by default or maybe only visible in the console log.

It should update on each refresh calling https://docs.nano.org/commands/rpc-protocol/#block_count
And check for "cemented". I think it will require the server docker container to be updated to allow block_count command.

Suggestion: Better notifications

When you copy text data to clipboard there is an alert window. I don't think that's the best approach since you can accidentally disable that on mobile for example and doesn't look very nice plus you have to close it with one extra click every time. A more common method is a custom notification display below the field you copy. For example at tools.nanos.cc I use this library but that's for react. https://github.com/fkhadra/react-toastify

There are tons of solutions for this.

Suggestion: Implement a "Max button" when sending

To automatically fill in the full amount sitting in the wallet. I know it's an appreciated feature existing in most wallets. But maybe also dangerous making people think it's the full amount when there is un-fetched pending.

Paper wallet string cutoffs

The address and seed look like they are missing the last characters, likely a style thing, the QR codes are correct though.
Correction: It is just the address string.

Fix and expand Landing page

The landing page does not work anymore now that we added the static routes for downstream.

We should work under the assumption that the landing page if changeaddress is set to true will have:

  • The set RPC url endpoint form with nano.linuxserver.io pre-populated
  • Have a blurb about what it is
  • Link to our github for the wallet

Wanna do a promo video and need a link people can use, this makes the most sense.

Suggestion: Use "Funds delivered" instead of "Funds received"

When detecting pending transactions you use the word "received". It's not what we should use here since it's not yet received (because you have to press the button to actually receive). Pending is what other wallets are referring to but what we most likely will move towards is to use the word "delivered". There has been a lot of discussions around that and most people seem to have agreed with that. At least it should not be "received", because that is both confusing and wrong.

Reference discussion: https://forum.nano.org/t/replacing-pending-terminology-once-and-for-all/329

Last I heard just a few days ago is NF going to take a decision on this soon and change their guidelines.

The string is referenced in home.vue and receive.vue

Bug: QR error message does not disappear

If scanning bad QR you get "QR code data does not conform to specification" but then scanning a correct QR will still show the message which is a bit confusing because you think it's still wrong.

Hide on-device keyboard when there is a wallet keypad

I saw this too on iphone, quite annoying having to close the keyboard on every key touch. A forced number keyboard would help as well. It's default now and I think that can be controlled from the app.

Also for POS terminal

Automatic check for pending

There is room for improvement for the receive procedure. That's where I got stuck the first time I used the wallet and that's not good. When you have the receive QR open, you scan it with a mobile wallet. Then you have to close that page, then press the refresh button, then press the receive button. Should probably be some text somewhere explaining this
It's very different from other wallets doing all this automatically

Or maybe add a scheduler that checks for pending every 5sec when the receive page is open, which would automatically close it and refresh.

Suggestion: Simplified url pattern

I like the ability to select backend API for the wallet but I'm not a fan of the long URL pattern. Right now using https://tix.nanos.cc/#/1.nanos.cc which does not look nice.

Suggestion is to add an optional alias to the store/app/state.js

'mynano.ninja': {
          alias: 'ninja',
          port: 443,
          path: '/api/node',
          protocol: 'https',
          headers: {
            'Content-Type': 'application/json'
          }

Then if the alias is present the URL would switch to example.com/#/ninja

Suggestion: Support import of nano seed

So right now it allows import of private key. I think it would be nice to also allow import of a seed. I don't think it can be detected if a 64 char hex is a seed or a private key. So maybe two fields are required. One for Nano Seed and one for Private key (which would automatically be computed if the seed is entered with account index 0 as default). Also an advanced interface where the user can select any index number.

Bad behavior in POS logic

  1. If sending amount larger than given, the notification is not shown (but balance reset as it should). This is true also if doing the payments in steps of smaller amounts.
  2. When making a request and paying it in full the polling for pending should stop. That works if paying the full amount in one transaction and also if overpaying in one transaction. But when paying in say two transactions and exactly matching the amount the last payment does not stop the API polling. Which means if you continue to do this in the same session you end up with an infinite amount of pollings per second. Bonus issue is the keypad automatically close on each poll it seems as well when in this state.
  3. If the pos account has one or more pending (made to the account since the last session) they will immediately be processed. I think that should be avoided if possible since it will mess with the actual request. That is, only care about pending made after setting the amount.

Suggestion: Redundant API end points

I was imagine some kind of load balancer or failover in case the main API fails. It could be done externally, for example using cloudflare but often involves cost. So what if building it directly into the wallet? A failover API that it will try if the first one fails/timeout? That could be another server with another nano node. Could be very useful when upgrading to a new nano node version for example and still want the wallet uninterrupted during the downtime.

The failover would probably happen after a certain timeout, lets say 2 seconds. However, a problem with this is if the API is down over a longer period all requests will be extended by 2 seconds. Another option would be to call all registered APIs for each call and use the fastest response. That would ensure optimal speed and uptime with the cost that all APIs will have to respond all the time.

Suggestion: Aliases

Aliases are still an overlooked feature in most wallets.

Recently vola and krypp added support for OpenCAP.

Perhaps its a good fit for this wallet as well.

Suggestion: A title for when last refresh was made

There is no websocket so it has to be manually (except for on the receive page where it can poll)

New users would expect to check for pending to be automatic so with a text that says "Last update: 2020-06-10 14:23" or "Last refresh: xx sec ago" would make it super clear you have to take action. People I spoke to who used the wallet didn't get you had to refresh it so I think this is important for usability. They also missed you had to press the Receive button (lazy people), but I'm not sure how to make that more clear. I have that info in my custom about page at least.

Suggestion: Allow more decimals in the account balance

The main balance show 0 when there is 0.00002 Nano (can be seen by hitting the ... but I think it can be confusing. What is the rounding limit here anyway? And if Nano increases 100x in value, it may be even more confusing.

Bug: Wallet load wrong address history from cache

Found a strange glitch. Are you able to replicate in your wallet?

  1. Go to the login page
  2. Type in /address/nano_xxx for a real address with some history
  3. Press back button to come back to login page
  4. Paste a seed (with empty history) and login
  5. Now it will load the previous watched account instead of the account belonging to the seed as seen by the account history that is filled when it should be empty? But it seems the actual account used in the wallet is correct as seen in the receive window, so maybe just the history that is not cleared correctly.

Suggestion: Quick generation of a new wallet

I find it a bit complicated to click the link at the bottom, generate a wallet and then copy the right field over to the first page (at the same time save the seed in a secure location). It's multiple copy/paste. I think it would be better to have a button for "New Wallet" on the front page that would generate the seed (and private key with account index 0). And suggest that the user save the seed before they can log in! Optionally also allow the user to export the seed from the settings page once they are logged in.

Styling backlog Adding Phrase File and Form ingestion

@KodeStar if you ever get some spare time and can take a look at these would be much appreciated. (all on the phrasefilelogin branch)

Phrasefile styling:

The advanced seed view from landing needs frontend touch:
Screen Shot 2020-06-29 at 17 43 57

Also the generate view, not sure if we want to hide these forms by default:
Screen Shot 2020-06-29 at 17 45 24

From the Generate page the about ! button page overlay has a cutout on the top where the RPC server info normally would be:
Screen Shot 2020-06-29 at 17 46 41

Checkout styling:

With the addition of the form rendering from remote Yaml to actually parse and send a signed payload to our new cart service you can use the two following yaml URLs to test layout: (checkout button from send)

https://www.nanocheckout.com/templates/f157d5ef-d3be-4b09-9fba-e973938cdc44 - this one renders minimal stuff but still styling is off:
Screen Shot 2020-06-29 at 17 49 50

https://www.nanocheckout.com/templates/f157d5ef-d3be-4b09-9fba-e973938cdc45 - this one adds the heavy default address info view and it is a mess, there is no page scrolling by default and the selects using the vue region select plugin are unstyled:
example

Let me know if you need anymore info.

Complete POS logic

The pos branch has a hodge podge of non working code, but it is a starting point for shifting the logic out of Home and into Receive.
Essentially the views will check their $route and if /pos we run some different logic outside of the standard polling in that it will stop polling once the receive amount is at or less than 0.

  • need to subtract the amount received from current amount if less than total amount regenerate new QR with new amount and update amount field
  • Once amount is <= 0 stop polling in POS view and reset QR to just address
  • Polling needs to happen on amount set without waiting the interval to get a current state of blocks while waiting for transactions

Basically all of this logic can be used/carried over to the standard home receive view outside of the polling start/stop if auto refresh is enabled. The QR should still reset on receives if amount set, the amount should still be deducted from, and instead of stopping the polling you just continue to display any new transactions like before.

Bug: Automatic pending in receive screen does no longer work

I have receiverefresh: true (store/app/state.js) but it does no longer refresh the pending while in the receive window (when logged in to the wallet), with or without an amount. It worked before so I'm not sure what broke it. Maybe the latest POS changes (which does work if just using the standalone pos window). Or it's me that screw something up. Needs investigation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.