This epic replaces issue #1

@mariocao suggested using commitizen.

Should cover:

• Tests
• Linting

In the light of #79 / #80, let's take this chance to add - 9 to the test suites in .travis.yml so it also tests for the project's "official" nodejs version.

Inside LevelDB, we should have both plain stores and encrypted stores.

Encrypted stores shall use symmetric encryption (AES/CBC/PKCS5Padding) in a transparent way.

Encrypted stores are unlocked using a user-defined passphrase.

Vuex helps managing the front-end state in a very efficient, hygienic and seamless way. It ensures that the state can only be mutated in a predictable fashion.

More info:
https://vuex.vuejs.org/en/intro.html

We should create a contribution guide to make it easier for people to know where to start from and what to take into account.

We can build upon the Aragon.js contributing guidelines.

Upon start up, Sheikah should read from LevelDB or initialize it if still empty.

Here's a curated list of UI component collections:
https://github.com/vuejs/awesome-vue#component-collections

Add the jest config file to the npm jest script in package.json file.

• Main interface
• Transactions list
• Receive UI
• Send UI
• Coin control UI

The private and public key serialization format is succintly described in wip-adansdpc-hdwallets, reproduced here:

Serialization format

Extended public and private keys are serialized as follows:

The key data field will be ser_P(K) for public keys and 0x00 || ser₂₅₆(k) for private keys.

This structure can be encoded using Bech32 format described in WIP-adansdpc-addresses. We will use 'xpub' human-readable part for extended public keys and 'xprv' for extended private keys.

When importing a serialized extended public key, implementations must verify whether the X coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.

We need to adapt the styling of our chosen base UI toolkit (see #65) to our UI design (see #12, #16 and #17).

• The application should be aware of the execution environment (dev/test/prod).
• This constant should be exposed to both the backend and the front-end.
• Default environment should be dev for the time being.
• Electron's developer console should only be visible while on dev environment.

Abstract

We will be making the most of Electron and React to ensure the app feels as native and responsive as possible. To do so, we need first to define a clear architecture that sets forth what will be happening in every part of our app. Clearly stating the responsabilities of both the Electron renderer and the main process is paramount to achieve a consistent and reliable architecture.

Background

Electron conveniently uses two separate processes to isolate the code that will be run in a node-like context (the main process) from the code that will be run inside a web-like context (the renderer process).

The main process

The main process has superpowers. Your code is run in a node-like context, so you have access to everything in the userspace of the host machine. This means you can have native access to the filesystem, hardware devices, etc. without having to deal with restrictive web APIs.

A node-like context also gives you the possibility to run Javascript bindings of natively implemented functions (through N-API), which is specially convenient for implementing performance-intensive code (cryptosystems and the like).

The renderer process

The renderer process is nothing more than web content running in a browser (WebKit). The APIs available in this context are exactly the same that you could expect when running Javascript code in a modern browser (including all ES6 and some ES Next).

Current architecture

Our current high level architecture design relies on the main process to act as a sort of back-end that will be responsible for taking care of persisting data in a local database (see #33), performing all the expensive operations related to crypto and brokering communication with rust-witnet, our full node implementation.

On the other hand, the renderer process acts as front-end or user interface. It is powered by React and relies on Redux to handle app state mutations in a consistent and robust manner.

The front-end back-end can communicate by passing messages to each other thanks to Electron's native IPC modules (ipcMain and ipcRenderer). The IPC connection itself is conveniently wrapped by a dedicated API with a series of modular handlers (see #27).

The dilemma

From this point, we can take to different roads:

Option A

• Exposing most of the the methods from back-end modules to the front-end.
• The back-end would have almost no business logic and all the app state would live in the renderer process.
• The back-end role would be limited to:
  • Managing data persistence.
  • Externalizing expensive cryptographic operations.
  • Bridging a socket connection to rust-witnet.

Option B

• Implementing all the business logic in the back-end.
• Limiting the role of the front-end to performing a few entry validations, handling all user interaction events and telling the back-end to trigger consequences.
• The app state would be maintained on the back-end, but we would need to put some replication/synchronization in place in order to ensure consistency with what the UI will show.

We need to sketch/design the UI/UX for the FTU (first-time-usage).

• Welcome message
• Wallet seed type selection (new, import, xpriv, hardware)
• Wallet seed backup
• Wallet seed import / confirmation
• Xpriv/Xpub import
• Wallet encryption password setting
• Address generation waiting splashscreen (e.g.: spinner)

The IPC API library is an IPC server that wraps and exposes backend methods to the frontend.

Describe the bug

Line 3 on CONTRIBUTING.md has a typo.

Change:

:tada: Thank you for being interested in contributing to an Sheikah! :tada:

for:

:tada: Thank you for being interested in contributing to Sheikah! :tada:

We must define the client architecture in more detail and write it down in order for everyone to be in the same page and give/receive feedback on.

As an example: we should define how communication between Sheika's front-end and back-end works (e.g.: websockets, etc.) and what's the policy for maintaining the state synced between both.

Discussion and decission on different parts of the client architecture should be done in separate GitHub issues / stories.

Remove typings/secp256k1 and use instead @types/secp256k1 npm package

It's time to define the wallet data structure.

Is your feature request related to a problem? Please describe.
The project root folder is polluted by a number of configuration files that won't see many changes once our the development stabilizes.

Describe the solution you'd like
Move all the configuration files into a new /config folder.

This includes, at least:

• jest.config.js
• tsconfig.json
• tsfmt.json
• tslint.json
• webpack.config.base.js
• webpack.config.development.js
• webpack.config.electron.js
• webpack.config.eslint.js
• webpack.config.production.js
• webpack.config.test.js

Describe alternatives you've considered
None. Feel free to counter-propose.

This is a continuation of #13.

In this case, we need to assess their compatibility and ease of use with React.

Here are some curated list of UI component collections:
https://github.com/brillout/awesome-react-components#ui-frameworks
https://hackernoon.com/the-coolest-react-ui-frameworks-for-your-new-react-app-ad699fffd651

We like Semantic UI so far, but we are open to exploring other options.

Our linting rules have been enforcing usage of arrow (binded) functions instead of traditional functions. However, some of us are finding that arrow function overloads are counter-intuitive:

// Traditional function overload
function foo(bar: string): void {}
function foo(bar: number): void {}

// Arrow function overload
const  foo: {
  (bar: string): void
  (bar: number): void
} = (bar: any) => {}

Type definitions also look kind of weird:

// Traditional function typing definition
function foo(bar: string): void

// Arrow function typing definition
const foo: (bar: string) => void

The purpose of this issue is to open a discussion on whether we should relax our arrow functions policy and allow usage of traditional functions in those cases where we believe them to be more convenient.

In that case, we should make a commitment to applying a not-enforced-by-the-linter clear policy on when it is acceptable to use arrow vs. traditional functions.

Add a .node-version with the version used in the project: 9.11.1, so we are all in the same page. I was using version 10 and bignum is no compiling in it at the moment.

We had challenges with vuex, so @kronolynx is exploring alternatives.
Progress on his findings shall be tracked here.

Here are some examples.

Before implementing any UI we need to create a set of reusable components, our own UI toolkit.

Related to #69 and #63.

This epic replaces and closes #2.