nos / client

The nOS Client

nOS Client

nOS is a blockchain powered virtual operating system that serves as the gateway to Decentralized Applications.

The nOS Client (Developer MVP Release) allows for the development of Decentralized Applications that interact with Smart Contracts in the back-end.

Getting Started with nOS

The standalone client installers can be found here. To build manually, the client can be cloned from GitHub and run using the development steps below.

Commands

# Cloning from Github
git clone https://github.com/nos/client.git

# Install dependencies and launch the nOS client
# This is used to start developing on the nOS client
yarn install && yarn start

# Testing command
yarn test

# Testing with debug (repl) command
yarn test:debug

# Distribution command (code signing certificates are required to make this work)
yarn dist

Contribute to this repository

We welcome contributions to the code base. If you are interested in becoming a contributor, please read the contributing guide that covers the following:

• Reporting bugs
• Suggesting enhancements
• Code contribution guidelines

There is a specific channel called develop on Discord to discuss development.

Contribute by building a dApp on nOS

Need some help with building nOS dApps? Check out our dedicated documentation website containing useful info for the following topics:

• nOS Client API Documentation
• Create nOS dApp Usage
• nOS Local Setup and usage

Check out the documentation of the Create nOS dApp CLI tool to get going quickly.

Resources:

• Create nOS dApp repository
• Create nOS dApp example (NeoBlog implementation)

Releasing

Automated Deployment

We use CircleCI to automatically create builds based upon git tags.

1. run yarn release --dry-run - Note if the output version tag/changelog is correctly generated.
2. run yarn release - This will generate the changelog, update the version in package.json and create and push a tag.
3. The deploys jobs will be triggered and upload the artifacts to Github Release page as a draft.

Manual Deployment: macOS

1. Export the following variables:
   1. CSC_LINK - This is the path to the .p12 certificate file
   2. CSC_KEY_PASSWORD - This is the password of the .p12 certificate file
   3. CSC_IDENTITY_AUTO_DISCOVERY - Set to false to disable usage of local keychain (By default it looks in your login keychain)
   4. GH_TOKEN - This is used to upload the artifacts to Github
2. Create the distributable, i.e. yarn dist.
3. Locate and upload the following files as these are required for the auto-updater to work:
   1. dist/nOS-1.0.0-mac.zip
   2. dist/nOS-1.0.0-mac.dmg
   3. dist/nOS-1.0.0-mac.dmg.blockmap
   4. dist/latest-mac.yml

Manual Deployment: Linux

1. Create the distributable, i.e. yarn dist.
2. Locate and upload the following files as these are required for the auto-updater to work:
   1. dist/nOS-1.0.0-linux-amd64.snap
   2. dist/nOS-1.0.0-linux-x86_64.AppImage
   3. dist/latest-linux.yml

Manual Deployment: Windows

1. Export the following variables:
   1. WIN_CSC_LINK - This is the certificate file in text format
   2. WIN_CSC_KEY_PASSWORD - This is the password of the certificate file
   3. GH_TOKEN - This is used to upload the artifacts to Github
2. Create the distributable, i.e. yarn dist.
3. Locate and upload the following files as these are required for the auto-updater to work:
   1. dist/nOS-1.0.0-win.exe
   2. dist/nOS-1.0.0-win.exe.blockmap
   3. dist/latest.yml

Generating hashes for the artifacts

• MacOS/Linux: shasum -a 256 ./* - Where the final argument is the location of the artifacts

client's Issues

Extract dapp.html into its own webpack repo

Goal is to move the dapp.html demo into a separate repo that we can share with users as a starting point for creating their own dApp implementations. Ideally, I'm thinking we should provide a simple webpack/React boilerplate that gives users a head start on creating a compilable webpack that works when they point nOS to localhost:<port>.

Allow "localhost:****" HTTP requests in the Domain Resolver (and don't call nameservice sc)

If the URL called is localhost with any port, i.e. localhost:80: don't call the name service smart contract, and load the URL directly from HTTP.

Chrome Inspector Appears on `yarn start`

When I run yarn start I'm greeted with a string of errors (output below) as well as Chrome's inspector tools.

2018-04-25 01:50:47.450 Electron[23851:11781402] *** WARNING: Textured window <AtomNSWindow: 0x7fcca6c36470> is getting an implicitly transparent titlebar. This will break when linking against newer SDKs. Use NSWindow's -titlebarAppearsTransparent=YES instead.
[23851:0425/015049.698881:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015050.663237:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015051.663608:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015052.662728:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015053.663120:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015054.662509:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015055.663207:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015056.662678:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)
[23851:0425/015057.662975:ERROR:CONSOLE(7323)] "Extension server error: Operation failed: : has no execution context", source: chrome-devtools://devtools/bundled/inspector.js (7323)

Add flow

https://flow.org/

Refactor RequestProcessor to process asynchronously.

Copy/paste from Discord conversation w/ extra notes at the end.

All our existing IPC requests so far have taken one of two flows.

• dapp -> API -> IPC -> load data -> return result
• dapp -> API -> IPC -> confirm with user -> return result

This one would look more like:

• dapp -> API -> IPC -> load data (?) -> confirm with user -> load data -> return result

I'm realizing there are some bigger implications with the way RequestProcessor works right now.
It's currently a queue, and we're only working with the latest request on the stack.
So we basically have 2 options here:

1. Keep the queue working like it is, handle this extra call to load data in the same way we have been where the next request can't start processing until this one finishes, but it prevents other things in the queue from kicking off till we're done.
2. Make the queue work a bit differently so all requests can happen asynchronously. This would require some extra changes for things that require user confirmation since we don't want one confirmation dialog to pop up on top of another one if two user confirmation requests come in.

I have an idea around how #1 would work, but it's going to be a little bit of a shift in thinking from the existing example of how to do this.

We will basically need more higher order components in the flow.

My thought is that, instead of having the component you're building right now (the one that has the window.confirm call inside of componentDidMount), you would instead need that logic to happen in a higher order component. Denying that would cause onReject to be called, otherwise rendering would continue down the HOC call chain.
If rendering continues down the chain, then we would have another set of withCall, withNullLoader, withRejectMessage, and withData steps that would actually perform/wait for the invocation to occur.
And your final component would just call onResolve with the result of the invocation call/

Going with option #1 will block the queue. I think that's fine for now.

Switching to option #2 will require a little bit of a shift in architecture. The actions will need to be reworked to support that.

As an example, if there are two invoke requests, and both get approved, we currently only have one invokeActions, and the store data would overwrite each other.

I know what we can do to work around this, but it won't work out of the box with what we have.

What I'm alluding to in that last message, is that instead of directly calling createActions from inside of our actions file, we can instead return a function that calls createActions with its own unique ID. That way, we always have a distinct store lookup ID that won't interfere with other calls being made. The question I haven't answered is how we clean old store data that we don't need anymore.

Document API

Measer of the disk space

Your issue may already be reported!
Please search on the issue track before creating one.

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Version used:
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0):
• Operating System and version (desktop or mobile):

Measer of the disk space

Your issue may already be reported!
Please search on the issue track before creating one.

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Version used:
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0):
• Operating System and version (desktop or mobile):

Client freeze after input wrong url format

Expected Behavior

Client should continue to work if I enter wrong url or not

Current Behavior

Client show error and doesn't work anymore

Possible Solution

Steps to Reproduce (for bugs)

1. Login to Client
2. Input "http://" press enter in browser
3. Client show error: TypeError: Failed to construct 'URL': Invalid URL
4. Can't use client anymore

Your Environment

• Version used:
• Environment name and version: node.js v8.8.1, yarn 1.6.0, npm 5.6.0
• Operating System and version: macOS Sierra 10.12.6

Double Clicking on the nOS Client Outputs Console Error

When I double click on the background of Electron, I receive the following console warning:

2018-04-25 01:56:51.800 Electron Helper[23856:11781545] Couldn't set selectedTextBackgroundColor from default ()

Steps to reproduce:

1. yarn start
2. Double click on the pink/blue gradient background of Electron.

New account creation issue

Cannot new create accounts by using nOS GUI.

Expected Behavior

It should accept passphrase and we can register new wallet accounts

Current Behavior

When trying to create new account using nOS GUI,
I cannot enter text, it seems text boxes disabled.
and cannot even click on Register button or Login.

Possible Solution

May be some older and newer operating system related fixes and extensive testing required

Steps to Reproduce (for bugs):

Steps mentioned in below GIF file link:
https://drive.google.com/file/d/1N0numsArmVb1Bf4h_1G1SqSkQREZSAtV/view?usp=sharing

Context

Working with multiple wallet account from my dApp and need to interact with smart contract from newly created accounts. So, my testing is not working properly.

Your Environment

• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0):
  Nodejs version: 9.11.1
  npm version: 5.6.0
  yarn version: 1.6.0

• Operating System and version (desktop or mobile): 14.04 (Desktop)

Error while loading shared libraries

# yarn start --debug
yarn start v0.27.5
$ concurrently -r "yarn run start-react" "wait-on http://localhost:3000/ && yarn run start-electron" --kill-others --success first
Starting the development server... /root/nos-client/node_modules/electron/dist/electron: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory error Command failed with exit code 127. error Command failed with exit code 1.

My Environment:
# uname -a
Linux nos-dapp 4.4.0-119-generic #143-Ubuntu SMP Mon Apr 2 16:08:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

nOSLocal environment from the nOs client settings does not use Neo local environment

When I choose nOSLocal environment from the nOs client settings, it does not use my Neo local private environment but instead an unknown environment.

Expected Behavior

when I choose nOSLocal in the client settings combobox, it should connect to a started Neo local environment from my computer.

Current Behavior

when I choose nOSLocal in the client settings combobox, it seems that the client is connected to an unknown server

Possible Solution

edit may 13th 2018: add a workaround

1. pull the lastest version of nOSLocal
2. clean docker container ($ docker system prune -a)

Steps to Reproduce (for bugs)

1. launch Neo local environment from my computer
2. launch nOS client
3. connect for the first time with testnet wallet
4. chose nOSLocal in the client settings combobox
5. logout nOS client
6. extract WIF from Neo local environment default wallet (neo> export wif AK2nJJpJr6o664CWJKi1QRXjqeic2zRp8y)
7. connect to nOs client with the extracted WIF

Context

Your Environment

• Version used: nOs local commit 49c96c4, nOS client commit 3795446

Prevent normal web browsing

We don't want normal links to work. We should highjack navigation with electron to prevent it.

Note that webview does not support event.preventDefault() on the will-navigate IPC event. Instead, we'll need to use preloadRenderer.js to prevent navigation. An example of how to do this can be found here: electron/electron#4191 (comment).

Refactor login layout

The user shouldn't see the address bar, sidebar, etc. before they've logged in. Refer to the dist/auth_login.html and dist/auth_register.html pages in the client-template repo for ideas of what this might look like.

Build confirm function wrapper for complex dialogs

Expected Behavior

The confirm redux action needs a wrapper to support more complex form dialogs. It should support complex interactions (more than just a string for its children) as well as being able to pass a result as arguments to onConfirm.

Current Behavior

The confirm redux action accept children string/node and an onConfirm callback that is not given any arguments.

Possible Solution

🤔

Steps to Reproduce (for bugs)

1. Checkout #109 & run client
2. Navigate to nOS settings
3. Click "Add custom network configuration"
4. Observe the complex dialog interaction

Context

#109 (comment)

Your Environment

• Version used: all
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0): all
• Operating System and version (desktop or mobile): all

Integrate browser tabs and controls

While surfing the nOS web, it would be nice to have an option to add multiple tabs, just like Chrome

2-way API for parent/client communication

Have the parent expose a set of standard functions to child dApps and pages.

Essential functions:

• Retrieve user address / hash (no permission necessary)
• Do Test Invocations (no permission necessary)
• Read from sc storage (no permission necessary)
• Request the creation & submission of transactions (i.e. send asset or send invoke smart contract) (user permission necessary)

Not able to login using wallet file

Not able to login using wallet file

Expected Behavior

I have selected the wallet option in the nOS client and imported the wallet file.It should recognized the account and authenticate

Current Behavior

I have selected the wallet option in the nOS client and imported the wallet file.It has recognized my account but it doesn't authenticate me saying invalid private key

Possible Solution

May be we should add functionality for recognizing the wallet private keys

Steps to Reproduce (for bugs)

1.Open nOS client
2.Select wallet option
3.Import wallet file
4.Select your account and try to login
https://drive.google.com/open?id=1RiqNOUeiC77x9xQlCi5oVwsLU2v39Wi4

Context

Ideally login has to happen using wallet file also

Your Environment

• Version used:
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0):
• Operating System and version (desktop or mobile): Windows 10 desktop
• nodejs version : 8.11.1
• yarn version:1.6.0
• npm version : 6.0.0

"Logout" breaks client

After logging in, clicking Logout returns the following error:

Stack trace:

TypeError: Cannot read property 'encryptedWIF' of null

mapPreviousAuthDataToProps
/src/components/Login/index.js:22
  19 | 
  20 | const { LOADING } = progressValues;
  21 | 
> 22 | const mapPreviousAuthDataToProps = ({ encryptedWIF }) => ({ encryptedWIF });
  23 | 
  24 | const mapAuthActionsToProps = (actions) => ({
  25 |   login: ({ wif, passphrase, encryptedWIF, publicKey }) => {

Fix `yarn dist`

There's a problem compiling now that we're using electron-json-storage:

➜ yarn dist
yarn run v1.5.1
$ yarn run build && electron-builder
$ react-app-rewired build
Creating an optimized production build...
Failed to compile.

Failed to minify the code from this file:

./node_modules/electron-json-storage/lib/storage.js:335

Read more here: http://bit.ly/2tRViJ9

error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c react-app-rewired build
Directory: /Users/mhuggins/Development/nos/client
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/Users/mhuggins/Development/nos/client/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c yarn run build && electron-builder
Directory: /Users/mhuggins/Development/nos/client
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/Users/mhuggins/Development/nos/client/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Clean dapp request queue from redux store on logout & navigation

We need to clean the request queue when the user logs or navigates away from the current dapp. Otherwise, we will continue trying to process old requests the next time the user returns to the dapp browser.

There are several options to consider for this:

• Keep the data in the redux store & clean it up when navigating away.
• Remove the requests from the redux store, instead keeping them in local component state. This might actually be better since the requests should only be considered relevant while viewing the dapp. This would not work if we want to support tabbed browsing.
• Keep the requests in the redux store, but associate them with a session ID. The session ID would correlate to a dapp ID (some unique ID that we generate each time a dapp is viewed or new dapp tab is opened). The queue for that session ID would have to be cleaned up when that dapp is closed.

Expand of the memory drive

Your issue may already be reported!
Please search on the issue track before creating one.

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Version used:
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0):
• Operating System and version (desktop or mobile):

Redux Architecture

Extract neon-wallet's new redux architecture into an npm package so it can be shared. This will serve as the bed for all user actions in the app.

Client Dashboard Layout Integration

Integrate the layout from the private dashboard repo into the client.

• Use mini menu: layouts_menu_side_mini.html
• White menu background
• White top bar
• Top bar = Chrome-like navigation bar (standard navigation + URL bar, add to favorites, notifications, menu button)

nOS Client not allowing to login after clicking on create account

Cannot click on login button after clicking on create account

Expected Behavior

Clicking on login should redirect to login page

Current Behavior

After clicking on register ,nOS client hangs and not allows the user to click/enter anything

Possible Solution

May be extensive testing required on windows and support for latest versions is needed.

Steps to Reproduce (for bugs)

1.Open nOS client
2.Click on create account
3.Try to click on login
https://drive.google.com/open?id=1YlEqtyUNJ3NwDs5-pFNxpZMuV_FNGM45

Context

This is a basic functionality,login functionality should work ideally

Your Environment

• Version used:
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0):
• Operating System and version (desktop or mobile):windows desktop
• node js : 8.11.1
• yarn : 1.6.0
• npm : 6.0.0

Add additional neoscan URLs in Network Settings

Currently users can only select networks from a set of predetermined neoscan URLs. We should let users add custom ones.

Show GAS fee on real invocation confirmation dialogue

Expected Behavior

Since invocations above 10 GAS are no longer free, users should be made aware of the fee when sending an invocation.

Current Behavior

The invocation dialogue is currently not displaying any fees when reviewing real invocations.

Possible Solution

Before sending a real invocation, the client should do a testinvoke, then display the fee information and the "expected output" retrieved from the test invocation in the invocation confirmation dialogue.
In the case they fee is <=10 GAS, set displayed fee to "free".
In the case it's >10 GAS, display total GAS fee - 10 as the displayed fee.

Improve the Loading Splash Screen with animated text and UI tweaks

Current Behavior

The current Loading splash screen does not indicate responsiveness and feels clunky due to the size and window controls.

Possible Solution

1. Change the Loading splash screen size to 275px x 330px
2. Remove the Window controls
3. Display animated text (with entertaining phrases) that changes with random 2-4 second intervals to indicate responsiveness.
4. Below the animated text, display individual loading steps.

Reference of good loading splash (Discord):

Change `getBalance` to take an address

We currently have getBalance in our API, which takes an asset ID or NEP5 script hash as an argument and retrieves the current account's balance for that asset/token.

I suggest we change this function to take two arguments, with the first argument being the address that we should fetch the balance for. This would make it more extensive in case another address balance is needed, and it could still work smoothly with the way our API works, e.g.:

nos.getAddress()
  .then((address) => nos.getBalance(address, NEO))
  .then((balance) => console.log(balance))
  .catch((err) => console.log(err.message));

dApp Browser

The MVP version of the dApp Browser lets users enter a domain name to access a Github Pages repo as a child view in the client.

The dApp browseer consists of:

• Domain resolver connected to the smart contract (look up domain in smart contract storage and resolve the target)
• Home screen (for the MVP this can feature a thumbnail list of Featured & New dApps)

Clean account data from redux store on logout

We're currently cleaning the "auth" data upon logout, but we should clean other data such as "balances" too.

NEO/GAS & NEP-5 Token Wallet Tab

Requires all basic wallet functions:

• View NEO/GAS Funds
• Make NEO/GAS Transactions
• View NEP-5 Funds
• Make NEP-5 Transactions

Loading splash on client start & page load

Right now the client shows a white window while it loads. It should display a loading process splash for a more responsive user experience.

Create Account and Saved Accounts (Encrypted)

On the authentication window, the Passphrase tab should provide the option for users to create new accounts, and to save them on creation or log-in.

Similar to neon-wallet, users should be able to select previously saved accounts (only encrypted keys) so they only have to enter their Passphrase to log in.

Reactify webview

https://github.com/MarshallOfSound/react-electron-web-view

Replace `alert` and `confirm` calls with components

• withPrompt HOC should use Confirm component.
• withRejectMessage HOC should use Alert component.
• Replace webview window.alert function with custom Alert component. We will have to change the behavior to be promise-based since we can't block JS execution.
• Replace webview window.confirm function with custom Confirm component. We will have to change the behavior to be promise-based since we can't block JS execution.

As part of this work, we will need to ensure these modals are provided one at a time using a queuing system. (This can be a simple redux state, similar to the request queue.)

Unit - integration tests of the nOS API

Context

We should start with implementing unit/integration tests for the nOS API as it's essential to track it's functioning

Attach assets to invocations

We should let users attach assets to invocations so they can run VerificationTransaction methods in their smart contract (accept payments with invocations).

Error when selecting network twice and going to account tab

An error occurs when selecting a network twice and going to the account tab

Expected Behavior

No errors should occur when going to the account tab

Current Behavior

An error does occur

Possible Solution

Haven't had a look into it yet

Steps to Reproduce (for bugs)

1: login to nOS
2: go to settings
3: switch networks twice (ex: testnet --> coznet --> mainnet)
4: go to account tab
5: Console should display an error regarding an action on an unmounted component

Context

I haven't seen any negative side effects of this issue - although it's a must-fix ^^

Your Environment

Yarn 1.6
Node LTS
windows

Electron container is not draggable

I'm unable to drag the client, so moving it to other windows without using some osx shortcuts is impossible

Relocate Breadcrumbs component from layout to current page

Having the AuthenticatedLayout component render the Breadcrumbs component doesn't make sense because it's not aware of the current route. Instead, the current page's component should directly render Breadcrumbs as its first child, with the rest of its child components/markup following.

Network setting (nos testnet, localnet, custom)

Allow users to select/configure the network they want to use.

• Users can add a network from their Settings tab. Only a neoscan API URL is required.

• Default network: nOS Local Testnet (nos-local configuration, 127.0.0.7 + default nos-local API ports)

• FUTURE: By default we want users to connect to the public nOS Testnet (TBA)

Authentication (Login with WIF/Encr. PK)

• When the client starts, users should be able to authenticate with their WIF or Encr. PK.
• The log-in splash is the first thing people should see when starting the application
• The last Encr. PK used should be stored when restarting the app for fast re-authentication using only password.

Address bar clears on page visit. Also doesn't refresh page on re-enter.

2 bugs:

• The address bar clears on visit.
• Entering the same URL of the visited page doesn't "refresh" the page.

Creating a production build (yarn dist) fails

Getting a minifying error when compiling the source for a production build. This should be fixed in react-scripts 2.0 and already has preliminary work done in branch fix/buildingIssues

Expected Behavior

yarn dist creates a production build.

Current Behavior

yarn dist fails (see screenshot)

Possible Solution

Update the fix/buildingIssues branch - rebase it to develop's HEAD - and fix whatever causes the tests to fail.

Steps to Reproduce (for bugs)

1. Checkout develop
2. yarn
3. yarn dist

Context

Creating a production build is critical for mass adoption.

Your Environment

• Version used: develop branch @ latest commit
• Environment name and version: node v8.11.0, npm 5.6.0, nvm 0.33.6
• Operating System and version: macOS Sierra

Incorrect error messages shown

Expected Behavior

For example:
When providing an invalid scriptHash with testInvoke (or any other API function)
There should be an error saying Invalid script hash: "${scriptHash}" (Which is thrown in the makeTestInvokeActions when validating the scriptHash)

This issue consists through every current action and should be fixed for every current action

Current Behavior

When providing an invalid scriptHash with testInvoke (or any other API function)
There is an error saying Invocation failed for operation "${props.operation}" on "${props.scriptHash}"

Possible Solution

Catching the correct error thrown in the actions (in this case the makeTestInvokeActions which should be caught with withRejectMessage in components -> browser -> RequestProcessor -> TestInvoke index.js

Steps to Reproduce (for bugs)

1. Execute nos.testInvoke('invaldScriptHash','xx',xx')
   .then(res => console.log(res))
   .catch(err => console.log(err));

--> err = Invocation failed for operation "${props.operation}" on "${props.scriptHash}"
err SHOULD be Invalid script hash: "${scriptHash}"

Context

It's currently not clear WHY testInvoke would fail because it gives a general error. With any error you get the same error message and developers won't know that their scriptHash is invalid

Your Environment

• Version used: latest on dev/master
• Environment name and version (e.g. node.js 9.6.1, yarn 1.6.1, npm 5.6.0): node, nvm LTS, yarn 1.6
• Operating System and version (desktop or mobile): MacOSX

Approve HTTP POST/GET requests for `nos:` protocol pages

When accessing an nos: domain dapp, the user should have the opportunity to approve/reject XHR requests. To do this, we may need to override the default implementations of fetch and XMLHttpRequest within the webview.

Add events to API

We want to trigger events to dApps via IPC when nOS becomes aware of certain things. The first event that we care about is when a new block becomes available.

• Add a pair of API functions called on/off (or subscribe/unsubscribe) so that dapp's can listen for events that we trigger.
• Add actions for fetching the current block height to nOS, and poll for updates at a reasonable frequency.
• From the dapp component, when a change to the block height is detected, trigger an event via IPC.

Here's an example of how a dApp might expect to use this:

const api = window.NOS.V1;

api.on('newBlock', (event) => {
  console.log('Block index: ' + event.index);
  console.log('Block height: ' + event.hash);
});

Move Settings button to left side menu

At the hackathon some users were looking for the Settings button on the left menu. Since there are no page-specific settings right now, it makes sense to move it to the left menu.