joincolony / purser

Interact with Ethereum wallets easily

Purser

Purser simplifies interaction with Ethereum based wallets. It supports both hardware and software wallets and provides a consistent and predictable interface to work with during dApp development.

Purser is:

Simple - Has an easy and intuitive API. Get started in minutes!

Predictable - Uses the same commands for all wallet types.

Sane - Maintains developer health by using proper error messages, validations and sanitisers.

Plug & Play - Supports Hardware (Ledger, Trezor) and Software (ethers.js) wallets out of the box.

Purser was brought to you by the fine folks at Colony. To learn more about Colony, you can visit the website or read the white paper.

Quickstart (software wallet)

To use the software wallet (based on the ethers wallet):

Installation

npm install @purser/software

Usage

Create a new wallet

import { create } from '@purser/software'

const wallet = await create();

console.log(wallet); // { address: '...', privateKey: '...', publicKey: '...' }

or open an existing one (based on the mnemnonic)

import { open } from '@purser/software'

const wallet = await open({ mnemonic: '...' });

console.log(wallet); // { address: '...', privateKey: '...', publicKey: '...' }

Documentation

Please see the documentation with detailed examples and explanations.

Packages

Purser is a monorepo consisting of a collection of Ethereum wallet libraries:

• @purser/core: A collection of helpers, utils, validators and normalizers to assist the individual purser modules.
• @purser/metamask: A javascript library to interact with the a Metamask based Ethereum wallet.
• @purser/software: A javascript library to interact with a software Ethereum wallet, based on the ethers.js library.
• @purser/signer-ethers: An implementation of an ethers signer to use with any of the purser compatible wallets.

To build and release

In the root directory:

npm i
npm run bootstrap
npm run build
npm run publish

To clean detritus and reset the repository:

./node_modules/.bin/lerna clean
npm run bootstrap

The future

We plan to add support more hardware wallets and other features that will make wallet interactions even easier. Stay tuned!

Contributing

We welcome all contributions to Purser. You can help by adding support for new wallet types, testing existing wallets, or improving the documentation.

Please read our Contributing Guidelines for how to get started.

License

The purser monorepo and each individual purser library are MIT licensed.

purser's Issues

Metamask Wallet improvements

This Epic tracks improvements needed (or just nice to haves, but that are planned) for the Metmask wallet.

Trezor Wallet check if the service is online

Since we are relying solely on Trezor's servers to operate the Trezor Hardware, it's a good idea to make sure that the service is up and running before attempting to create the new TrezorWallet instance.

This could be done by making a OPTIONS fetch() request to the Trezor service and checking if the reponse status is 200.

Ledger Wallet Hardware Detection

This issue serves to track implementation of hardware detection on the local machine, for the Ledger Wallet.

Currently this is not possible using the U2F transport.

This will become viable once WebUSB gets mainstream adoption.

Refactor providers

This is an Epic that keeps track of all the issues related to refactoring providers.

Warn the user about Trezor's Message Signature Format

Trezor signs the message in a different format from the standard one, and as such, external services like MyEtherWallet, MyCrypto or Etherscan can't verify the signature.

It can however be verified by the device internally since it uses the same algorithm to reverse it, which results in a correct signature validation.

Nonetheless we should warn the user about this when trying to call both signMessage() and verifyMessage() methods.

Feature planning

This PR is here to track planned features, as well as to track new proposals. Just add comments.

Needed features:

• Hardware wallet support: Trezor
• Hardware wallet support: Digital bitbox
• Hardware wallet support: Ledger Nano S
• Browser extension support: Metamask
• Software wallet expose (with docs) basic transaction methods (eg: sign(), sendTransaction()) #26
• Software wallet signWithPrompt() method. Done in #32

Maintenance

• Rename localhost() provider method #34

Feature proposals:

• Custom token balances (something like: balanceOfToken('tokenName', 18), keep a registry of well-known tokens, and have a way to "register" new ones)

Ledger WebUSB transport

This issue serves to track mostly adoption of the WebUSB API standard.

Once that happens we can assign resources to develop a ledger transport based on that, which will make accessing the wallet a lot more easier.

Software Wallet expose the `signMessage()` method

Even though the signMessage() method is available to the user in the Software Wallet via it's inherited prototype (Remember, we're extending ethers's Wallet class), it's not easily visible trough Object discovery or prop enumeration.

We should expose this method directly on the SoftwareWallet instance.

Along the way we should normalize and validate both the input and the output.

Software Wallet shouldn't expose the `privateKey`

There's an argument to be made that we should withhold the privateKey (or the mnemonic, or the keystore) from the end user, from the standpoint of security.

The user will be able to interact with the wallet normally, but to prove his/her identity it must sign and verify a message (like all other wallet types expect you to do)

This will provide a more consistent mode of operation between all the wallet types.

On the other hand, the user already used one of those methods to open the wallet, so there's also the reverse argument that they are already known, so what's the point of hiding them?

Mininal Needed Featureset

This Epic is here to track the minimal features needed for this library to be useful and cover the features needed by the dApp.

This might not necessary cover all the features that are needed for a proper release into the wild, but at first we're concerned with integrating it in the dApp.

Metamask verify message static method

This issue tracks implementation of the verifyMessage() static method for the Metamask wallet.

This method takes in a SignatureObject and returns true or false based on if the current address indeed signed the message.

This will make use of Metamask's version of web3.personal.ecRecover method.

Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation

Software Wallet expose the `sign()` method

Even though the sign() transaction method is available to the user in the Software Wallet via it's inherited prototype (Remember, we're extending ethers's Wallet class), it's not easily visible trough Object discovery or prop enumeration.

We should expose this method directly on the SoftwareWallet instance.

Along the way we should normalize and validate both the input and the output.

Self-generate the Software Wallet

At this point (after #56 and #57) we are in a position where we're able to write our own Software Wallet generator.

If we do this we remove reliance on external libraries like ethers and all the extra weight that comes with.

While this is a nice improvement, it should obviously come at a later stage.

Trezor hardware wallet integration

This issue tracks integration of the Trezor hardware wallet into the lib.

It should have the usual needed features:

• open an existing wallet
• sign a transaction
• hardware detection ?

Lazy load node `crypto` library

The getRandomValues(), if it can't find the built-in webcrypto API (or is running in a node-only environment) will fallback to using node's own implementenation -- crypto library.

The way it's currently set up, it will load the code upfront in the bundle.

This can be further optimized by lazy-loading the code only we really needed.

Software Wallet expose the `verifyMessage()` method

Even though the verifyMessage() method is available to the user in the Software Wallet via it's inherited prototype (Remember, we're extending ethers's Wallet class), it's not easily visible trough Object discovery or prop enumeration.

We should expose this method directly on the SoftwareWallet instance.

Along the way we should normalize and validate both the input and the output.

Remove Providers in Trezor Wallet

As planned in the Roadmap, we are phasing out providers from this wallet library and offloading that functionality to the end user.

This library will not be responsible for communicating with the blockchain, it should function as an offline wallet.

This Issue serves to track the refactoring work needed to make this happen.

Increase flow type coverage

Right now the projects's type coverage hovers somewhere around 65-70%.

I want this to go over 80%.

While this is not a big hurdle, in the interest of time, this is not a priority and will be backlogged (until all wallet types are implemented)

Also, this should add a flow coverage reporter (eg: flow-coverage-report) and set that up as a CI step.

Software Wallet better handling of the derivation path

PR #60 brings in a lot of utilities to validate, normalize, serialize and de-serialize the derivation path.

We should use them to provide safety checks for the derivation path in the Software Wallet as well.

An in-range update of eslint-plugin-flowtype is breaking the build 🚨

Version 2.47.0 of eslint-plugin-flowtype was just published.

Branch	Build failing 🚨
Dependency	eslint-plugin-flowtype
Current Version	2.46.3
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-flowtype is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ ci/circleci: build-with-lockfile Your tests failed on CircleCI Details

---

Release Notes

v2.47.0

<a name"2.47.0">

2.47.0 (2018-05-22)

Features

• Refactor array-style-... rules (6320beec)
• Improve error messages (b95dd31d)
• Change default array notation for simple types to "verbose" (687f82be)
• Implement fixation in array style rules (4a6f03d9)
• Implement array style rules (afd42108)

Commits

The new version differs by 10 commits.

• 45e86d8 Merge branch 'pnevyk-feat/array-style'
• 1d664d7 docs: correct documentation
• a916617 Merge branch 'master' into feat/array-style
• 8f86c4b docs: add eslint-config-flowtype-essential (#328)
• 6320bee feat: Refactor array-style-... rules
• b95dd31 feat: Improve error messages
• 687f82b feat: Change default array notation for simple types to "verbose"
• 4a6f03d feat: Implement fixation in array style rules
• afd4210 feat: Implement array style rules
• 1232069 docs: Add documentation for array style rules

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Metamask only sign the transaction (and don't broadcast it)

Metamask currently only allows us to boardcast the transaction when signing it. We can't just sign it, and then broadcast it some other way.

This is a limitation for us since this library is an offline wallet (well, with the exception of this anyway...)

This is issue is here to keep track of Metamask's development, and when (or if) it gets implemented, bring the functionality in.

Issue to track: MetaMask/metamask-extension#3475

Ledger hardware wallet integration

This issue tracks integration of the Ledger Nano S hardware wallet into the lib.

It should have the usual needed features:

• open an existing account
• sign a transaction
• hardware detection ?

Validate user facing method input to ensure it's and Object

This is due to the fact that all user facing method take arguments as a single Object with varying number of props, and not the arguments directly.

We should warn the user that the arguments provided are not correct and maybe link to the documentation.

Most likely this will be done by creating a function factory.

Remove Providers in Ledger Wallet

As planned in the Roadmap, we are phasing out providers from this wallet library and offloading that functionality to the end user.

This library will not be responsible for communicating with the blockchain, it should function as an offline wallet.

This Issue serves to track the refactoring work needed to make this happen.

Software Wallet remove extraneous features

The library should provide a core wallet experience, without making assumptions about the environment, be extra opinionated or bundle in extra "features".

Although initially I thought they would be nice additions, I've came to the conclusion that they would only be extra weight to the library.

To that affect, we should remove from the software wallet library:

• private key and address built in qr code generator
• address blockie generator

Refactor providers to accept arguments as an object

This was already implemented in the software wallet module, since it works there, it should be brought over to the providers module as well.

The idea is that the provider generator methods should instead of a number of arguments, accept only one, which is an object.

This helps with allowing the developer to pass in arguments (as that object's props) in any order, and won't require passing in undefined or null when wanting to skip an argument.

So, from this:

const etherscan = (network, token) => {...};

To something like this:

const etherscan = ({ network, token }) => {...};

This change should not take long to implement (mostly checks for object props), but the unit tests will take a while to change into the new format.

Metamask browser extension integration

This Epic tracks integration of the Metamask browser extension into the wallet library.

It should have the usual needed features:

• access existing account
• sign a transaction
• sign a message
• verify a signed message
• availability detection

Note

Please merge all issue PR's branches into the main metamask implemenation branch (feature/59-metamask-integration), and only after all of them are done, merge the main class into master.

Improve warning/error message imports

When working in development mode, we output a variety of warning or error messages to the console.

The way they are set up currently is they all reside in a message.js file, which gets imported when needed to display them.

In production mode the messages won't be shown anymore, as they are suppressed by the warn() and error() methods.

Problem is, those messages still get imported, and the methods are still called, even if they don't output anything. To make it even worse, all the messages get imported even if you tree-shake and just a use one module out of the library.

And as time goes on, this file will only get bigger.

Right know, I see three possible approaches to this:

• Remove the centralized file, and declare messages per-module.
• Don't import them when in development mode (this would be best)
• Tree-shake them, so that only the module's messages get imported

This should be prioritized before the first release of the library.

Prepare package for release

This issue is here to track (and remind of) the needed changes that are required to the package in order to be released via Github and NPM.

• Add correct folders to the package.json entry (dist was changed to lib)
• Add pre / post install hooks
• Update descriptions, titles, contributors, license
• Update readme.md with colony logo / header
• Fix #16

Remove Providers in Software Wallet

As planned in the Roadmap, we are phasing out providers from this wallet library and offloading that functionality to the end user.

This library will not be responsible for communicating with the blockchain, it should function as an offline wallet.

This Issue serves to track the refactoring work needed to make this happen.

Catch errors coming from Trezor's `signMessage` static method

It basically needs the call to the Trezor service to be wrapped inside a try/catch block and have a nice error message presented to the user.

Both other methods, signTransaction() and verifyMessage have this, but apparently this one was overlook during initial development.

Software wallet module quality-of-life improvements

This issue is here to track small improvements that could be made to the software wallet module, but that are not currently urgent, so they are relegated to the backlog.

Improvements:

• Check for erroneous / similar prop names (when passed in as arguments). Eg: password vs. pasword. See: https://github.com/JoinColony/colony-wallet/blob/bb2d586374e30b03a108f418c742420757ae826c/src/software.js#L52-L58
• When opening the wallet, detect if a method was passed in, but it was invalid, and warn the user about it. See: https://github.com/JoinColony/colony-wallet/blob/bb2d586374e30b03a108f418c742420757ae826c/src/software.js#L282-L313

Rename `localhost` provider method

In not one of my proudest moments, I've named the method that connects to a json-rpc service as localhost().

In retrospect this name choice is very poor and should be remedied.

Firstly because it's confusing and secondly because you can connect to json-rpc server that is not hosted on your local machine...

Good names alternatives: jsonRPC() or jsonRpc().

TODO

• Rename method in providers.js
• Change method name in providers autoselect() method
• Change method name in unit tests
• Change method name in documentation (docs/api.md)

Fix Trezor Wallet transaction signature

I have a hunch that the signature returned for a transaction will not be accepted into providers like Etherscan.

This is due to the fact that the initial transaction object is not seeded with the signature's R, S components and the V recovery parameter.

See the Ledger implementation for reference:
https://github.com/JoinColony/colony-wallet/blob/0298bd6087690394c18044c82f9de17914baa50d/src/ledger/staticMethods.js#L114-L130

Trezor Wallet Improvements

This Epic tracks improvements needed (or just nice to haves, but that are planned) for the trezor hardware wallet.

Async all the things ?

Background

This is how the wallet object looks right now:

{
  address: "0x75a..." // string containing the address

  addressQR: (...) // async getter that returns a qr code image of the address

  blockie: (...) // async getter that returns a blockie image of the address

  defaultGasLimit: (...) // getter that returns the gas limit as a number

  keystore: (...) // async getter and setter that returns the encrypted keystore (optionally sets the password for encryption)

  mnemonic: "outer tissue..." // string containing the mnemonic

  path: "m/44'/..." // string containing the mnemonic path

  privateKey: "0xac2..." // string containing the private key

  privateKeyQR: (...) // async getter that returns a qr code image of the private key

  provider: (...) // getter and setter for the provider object

  sign: (transaction) // transaction signer method 
}

We have three main ways of opening a wallet: (returning a new instance)

• via a known private key (will return the whole wallet object, barring the mnemonic and path) -- currently implemented
• via a known mnemonic seed (will return the whole wallet object) -- currently implemented
• via a known encrypted keystore and accompanying password (will return the whole wallet object) -- not implemented

keystore encryption / decryption is a heavy operation (that's why the getter is async and memoized)

The software wallet module exposes two methods, open() and create() which both take in parameters in the form of an object (so they can be passed in any order)

Example:

import { software as wallet } from 'colony-wallet/wallet';

const newWallet = wallet.create();

const existingWallet = wallet.open({ privateKey: '0xac2...' });

Problem

Creating a new wallet is a synchronous operation, since anything that's heavy is deferred under async getters until the user needs those values. (keystore, qr code images, blockies...)

Opening the wallet is as well synchronous (in the current implementation, using only private key and mnemonic).

The problem starts when trying to add the 3rd opening method, via keystore / password. This is an async operation and will return a Promise.

Implemented naively this will screw with the expected return value of the open() method as in two cases it will return a wallet Object, one case a Promise, and a fourth case of undefined in case something throws an error.

Potential solutions

1. Implement via another method

Since we're using ethers as a backbone for the software wallet, we can just do as they do and have another method.

But this really isn't an elegant solution

Eg;

export softwareWallet = {
  create, //sync
  open, //sync -- private key, mnemonic
  openWithKeystore, // async -- keystore
};

2. Drop keystore support

We could just not support it, either temporarily (for the MVP) or permanently. But I don't want to cripple the library like this.

3. Partial asynchronicity

We can have the open() wallet method be async. This way we have a constant return type when opening a wallet.

Eg:

export softwareWallet = {
  create, // sync
  open, // async -- private key, mnemonic, keystore
};

import { software as wallet } from 'colony-wallet/wallet';

const newWallet = wallet.create({ entrophy: new Uint8Array(42) });

const existingWallet = await wallet.open({
  keystore: '{"address": "0xac2..."}',
  password: 'decrypt-me-baby',
});

4. Full asynchronicity

While making the open() method async is nice for supporting all three wallet opening methods, it brakes consistency with the rest of the library which is mostly synchronous.

But making everything return a Promise will solve that. And not just the wallet open() and create() methods, but extending this to the whole library, providers included.

(Actually for providers this is a nice thing, since it would allow me to improve the JsonRPC provider and actually check the connection when initiated, not just when you want to have a transaction)

My gut feeling says to go with this since an fully async library would actually make sense, especially in the context of ethereum.

Eg:

import { software as wallet } from 'colony-wallet/wallet';

const newWallet = await wallet.create();

const existingWallet = await wallet.open({ mnemonic: 'outer tissue...' });

---

@thiagodelgado111 @coyotespike @chmanie @JamesLefrere

If you managed to read through this, any thoughts, opinions or ideas are greatly appreciated 👍

Metamask availability detection

This issue tracks implementing a static method to detect if the Metamask extension is available, and maybe, detect if it's unlocked or not.

This can be done by basically checking for the availability of the web3 global object. (injected by either Metamask or Mist): https://github.com/MetaMask/faq/blob/master/detecting_metamask.md#detecting-metamask

Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation

Metamask sign transaction static method

This issue tracks implementation of the sign() static method for the Metamask wallet.

This method takes in a TransactionObject and returns the transaction's signature, in hex string format. This can then be sent to the blockchain via a provider.

Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation

Note

Most likely this will be a hard blocker!

This is because Metamask doesn't trust it's users to sign they're transactions without also broadcasting them.

See: MetaMask/metamask-extension#3475

An in-range update of webpack is breaking the build 🚨

Version 4.9.1 of webpack was just published.

Branch	Build failing 🚨
Dependency	webpack
Current Version	4.9.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ ci/circleci: build-with-lockfile Your tests failed on CircleCI Details

---

Release Notes

v4.9.1

Bugfixes

• fix parameter references in default parameters

Internal changes

• change test cases to text format

Commits

The new version differs by 11 commits.

• 94cd709 4.9.1
• 5feb7e6 Merge pull request #7174 from JLHwung/revise-examples-build-readme
• 4cd0cf5 Merge pull request #7379 from xtuc/refactor-use-wast-in-tests
• c513cac Merge pull request #7403 from webpack/fix/7335
• f22fffd Evaluate arguments in function's scope
• 55ce143 Add test case
• 00eafa6 Update mem-access.wat
• acc45fd refactor: switch to wast
• 7184bb4 fix: keep decoding in wasm
• a9d9fee refactor: switch to tests to wast
• 64db306 docs(examples): add yarn add webpack-cli step

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of ethers is breaking the build 🚨

Version 3.0.16 of ethers was just published.

Branch	Build failing 🚨
Dependency	ethers
Current Version	3.0.15
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

ethers is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci: build-with-lockfile Your tests failed on CircleCI Details

---

Commits

The new version differs by 1 commits.

• 3cb21dd Added timestamp to EtherscanProvider history (#174).

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Replaced the old Node.js version in your .nvmrc with the new one

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Software wallet account transaction and operation methods

Ethers have a number of methods available on the wallet that are used to send and receive transactions and manage various aspects of the wallet.

The problem is, they are hidden under the instantiated's wallet prototype and cumbersome to use.

This issue is here to track which ones we need on our software wallet module, expose them via the SoftwareWallet Class and improve them where needed.

This should be treated on a case by case basis as for some of the methods it might make sense to even re-write them ourselves or set them up directly in the Wallet Object (eg: getBalance could easily be an async getter prop)

Digital Bitbox hardware wallet integration

This issue tracks integration of the Digital Bitbox hardware wallet into the lib.

It should have the usual needed features:

• open an existing account
• sign a transaction
• hardware detection ?

Metamask sign message static method

This issue tracks implementation of the signMessage() static method for the Metamask wallet.

This method takes in a MessageObject and returns a signature for the message, which than can be used to verify it.

This will make use of Metamask's version of web3.personal.sign method.

Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation

Implement wallet auto select/open method

After all the methods to create a new Wallet instance are implemented in #8 (private key, mnemonic, etc...), a nice improvement will be a helper method that detects the way you want to open the wallet.

It has to detect if you passed it in a private key, encrypted json, mnemonic, brain wallet (?)

Since this is not a high priority it will sit for now in the backlog and not be implemented together with #8

Ledger Wallet Improvements

This Epic tracks improvements needed (or just nice to haves, but that are planned) for the Ledger hardware wallet.

Software Wallet Improvements

This Epic tracks improvements needed (or just nice to haves, but that are planned) for the software wallet.

Revisit perfomance testing

I'm putting performance testing in the backlog for now since it requires digging deeper into node's and v8's internals. (and right now the priority is to get the wallet up and running)

The way performance testing is supposed to work is to run through wallet methods (eg: create()) a large amount of times and average the completion time. This way we can test when adding new features that the wallet creation process remains under a certain `.

Problem is different environments have wildly different results.

Examples (all values in the arrays are in ms, for a number of 10 runs):

Chrome:

[ 153, 115, 96, 99, 97, 94, 95, 95, 90, 97 ]

Node:

[ 309, 272, 251, 242, 246, 247, 244, 244, 244, 244 ]

Jest:

[ 699, 684, 665, 660, 649, 662, 653, 659, 649, 665 ]

This needs to be investigated further, otherwise we won't be able to rely on these values.

Initially this was attempted during the #8 PR.

I've attached a patch with the initial code setup so when we revisit this, my work won't be lost / repeated (but since Github doesn't allow patches for some reason, I had to add it to a gist)

https://gist.github.com/rdig/f80a4ca1a4a4d3fbc1c73a6543c8bff6

Metamask main class instance

This issue tracks implementation of the main Class and the open() static method of the MetaMask wallet.

This will involve refactoring the core module's genericWallet class to support instating it with just the address (currently it needs both the publicKey and chainCode to derive the addresses indexes)

Unlike the other issues that tracked a wallet's implementation (which added them at the end of implementation), since this is a smaller one, it will also include adding relevant unit tests and documentation

Trezor Wallet Hardware Detection

While this is just a nice to have feature, I think there is a way to detect if the Trezor Hardware wallet is connected to the local bridge and, based on that, provide a status back to the user.

A rough idea on how to implement this, is to POST a message directly to the trezor service (directly POST not through the window's Object instance post() method) and listening for a response.