Current implementation is missing the signer_importMnemonic method, as shown by #55

Describe the bug

I'm using signer_importMnemonic with the options

{
    "description": "my new mnemonic",
    "hd_path": "m/44'/60'/160720'/0'",
    "mnemonic": "theory attitude bridge myself real exit ozone relax alpha cool bone license piano rival approve squirrel chuckle cross parade gorilla lion exercise harbor vibrant",
    "name": "my new mnemonic name",
    "passphrase": "12345678"
},
{
  "chain_id": 61
}

and i get the following error:

{ code: -32602, message: 'Keyfile storage error: KeyFile storage error: No storage for: ' }

works fine if i use { "chain": "etc" }

Is your feature request related to a problem? Please describe.
add signTypedData

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md

This is interrelated to #79, the latest JSONRpc Server allows us to use rust syntax generation to simply impl a code generated trait. This actually requires rewriting the server layer of jade signer.

Motivation:
Updating the server layer will help fix #79 , by providing a consistent interface that corresponds to the json-rpc document. This leads to a rewrite of the server layer as we no longer have to write custom endpoints for signer.

Acceptance Critieria:

Jade signer serves the open-rpc api using generated typings .

We should be using semantic release for this, such that we never have to have manual steps to produce a build.

See any of the OpenRPC repos for examples of this.

Alternatively, we could set it up with our jenkins, since we will need multi plat builds.

We are missing a key method to just sign messages. here is the openrpc for it:

Summary:
Current code still has references to emerald environment variables that were specified to make changes to the default settings for jade signer.

Acceptance Criteria:
Jade Signer should either make environment variables args, or use JADE_SIGNER prefix for environment variables

Describe the feature request:

rename methods to signer_ prefix

Jade Signer creates all keyfile database entries for all networks at boottime. Essentially, the networks supported by signer are hardcoded to rocksdb paths that are created at start time. This is problematic, because there are chainIDs that are not necessarily known at launch time.

We'd like to support sidechains and other networks with differing chainIDs. Not all will be known in advance.

Acceptance Criteria:
Jade Signer supports dynamically creating keyfile entries for chainIDs at request time, vs pre allocating at start time.

Currently Jade Signer doesn't support the expressive ness of the open-rpc document. All the Json-RPC API interfaces don't respect individual params to be serialized ( as far as I can tell).

Motivation: We want to provide a nice logical interface for devs to interact with jade signer, this means that for request like export_Account. The format should not be

export_Account( {address: "0xBEAD.."}, {chainID: 61}) but preferably
export_Account("0xBEAD",61); Where the client type annotations inform the developer what is what. Additionally we should still support the former interface where it makes sense

Acceptance Criteria:
Jade Signer accepts single variable arguments to rpc request, meaning it supports named params and positional params.

Pull requests should test that the project builds, and the tests pass.

Summary:
Accounts in Jade signer are keyed currently from the chainID. This is fine when you aren't switching chains. However, as we move forward towards L2 scaling solutions, we hit problems supporting cross chain requests.

Motivation:
ChainID is the prefix for all account actions, when account addresses should be chain agnostic.

Acceptance Criteria:
Jade Signer stores account address information not keyed by chainID

Here is the spec pr if you have any feedback:
open-rpc/spec#81

The idea is to have a method called openrpc.discovery that will return the contents of the openrpc.json file

it was added to .gitignore, but it needs to be removed from git

when adding sign, it needs to take the passphrase separately than the data, unlike signTransaction (it takes passphrase with the transaction).

we should make this consistent, and take it as another parameter.

Describe the bug
error: multiple packages link to native library 'rocksdb', but a native library can be linked only once

To Reproduce
Steps to reproduce the behavior:

1. clone repo
2. cargo build
3. See error below

Expected behavior
I expect to see a build without errors

Desktop (please complete the following information):

• OS: Mac OSX

➜  jade-signer-rpc git:(master) ✗ cargo build
error: multiple packages link to native library `rocksdb`, but a native library can be linked only once

package `emerald-librocksdb-sys v5.11.3`
    ... which is depended on by `emerald-rocksdb v0.10.3`
    ... which is depended on by `emerald-rs v0.25.6`
    ... which is depended on by `jade-signer v0.1.0 (/Users/shanejonas/etclabs/jade-signer-rpc/signer)`
links to native library `rocksdb`

package `librocksdb-sys v5.17.2`
    ... which is depended on by `emerald-rocksdb v100.0.0`
    ... which is depended on by `jade-signer-rs v0.1.0 (/Users/shanejonas/etclabs/jade-signer-rpc/jade-signer-rs)`
also links to native library `rocksdb`

these arent needed, we can use #23 for that

Summary:
Currently Jade Signer does not have full support for network variants. In order to support this Jade signer needs to be refactored to have chainID as the primary method of interacting with signer.

Acceptance Criteria:
Jade signer RPC interface shoudl require chainID specification for each method, and the underlying signer interface should support chainID reference. The refactoring should remove network name specification. Network name specification should be pushed to downstream projects.

Implement property based testing (aka. generative testing) using quick check

we use passphrase everywhere else. we need to keep the usage consistent.

Describe the feature you would like
This repo should be using pristine to get a license, better baseline documentation, and encourage contributions.

Describe the solution
https://github.com/etclabscore/pristine#how-to-use-pristine-in-your-project

for the rpc.discover JSON-RPC method. it should return the openrpc.json in this repository

Summary:
Jade Signer needs some TLC, I'm modernizing Rust, as well as stripping some of the speculative features. I'm using this as the mega tracker for the effort, as I've gone deeper down the rabbit hole there are lots of little things that need refactoring. Dead code paths, and some of the interfaces that no longer serve what we're trying to do.

Motivation:
Have one tracking issue for all the work going into getting jade signer up and running with best practices and a cleaner code base. This will help us with the wallet and supporting side chains.

Acceptance Criteria:
Jade Signer works as specced by open-rpc document.
The following issues are resolved.
#80
#81
#74
#25
#72
#79
#78
#77
#70

• Update docs for stripped functionality and CLI interface
• Update Readme

does the openrpc.json have to be shipped beside the binary for this to work?

Originally posted by @shanejonas in #35

We currently use parity's json-rpc library to make request. The library version we use is 8.0 HEAD at this moment in time is 14.0 .

Motivation:
The upgrade would include websocket and built in named parameter support as well as potentially better error handling.

Acceptance Criteria:
We are at latest version of the json-rpc library, and this is reflected across our client generated tools as well.

Describe the bug
Testing against open-rpc-test-coverage fails:

To Reproduce

1. Run the server
2. open-rpc-test-coverage -s ./openrpc.json --transport=http --reporter=console

Expected behavior
Clear and green test run

Log

Example Validation Error:  signer_newAccount
params:  [
  {
    name: 'my test wallet',
    description: 'my test wallet description',
    passphrase: 'baz'
  },
  { chain: 'etc' }
]
result:  0xcfd0078e959c72404783cb289b8f050c79e88e0e
examples:  [
  {
    name: 'newAccountExample',
    description: 'Example of creating a new account',
    params: [ [Object], [Object] ],
    result: {
      name: 'newAccountResultExample',
      value: '0xae6645b12af5f3d76d854f9cbe514476f9b110fb'
    }
  }
]
method object {
  name: 'signer_newAccount',
  summary: 'Creates a new account and stores it locally as a passphrase-encoded keystore file.',
  params: [
    {
      name: 'newAccount',
      description: 'Creates a new account and stores it locally as a passphrase-encoded keystore file.',
      schema: [Object]
    },
    {
      name: 'additional',
      summary: 'additional params',
      description: 'additional list of parameters to define network or account specific options',
      schema: [Object]
    }
  ],
  result: {
    name: 'address',
    summary: 'Account address',
    required: true,
    description: 'hex-encoded 20 bytes public address',
    schema: { type: 'string', pattern: '^0x[a-fA-F\\d]{40}$' }
  },
  examples: [
    {
      name: 'newAccountExample',
      description: 'Example of creating a new account',
      params: [Array],
      result: [Object]
    }
  ]
}
JSON-RPC Request Error:  signer_importMnemonic
{ code: -32601, message: 'Method not found' }
[
  {
    name: 'my imported wallet',
    description: 'my imported wallet description',
    passphrase: 'baz',
    hd_path: "m/44'/60'/160720'/0'",
    mnemonic: 'icon suggest road current ripple engage spell clay route large arena climb oxygen electric cupboard dream title immune fit beyond mouse slab bronze salad'
  },
  { chain: 'etc' }
]
JSON-RPC Request Error:  signer_listAccounts
{
  code: -32602,
  message: 'Invalid data format: Required chain name or chain id parameter'
}
[ {} ]
JSON-RPC Request Error:  signer_unhideAccount
{ code: -32602, message: 'Corrupted input parameters' }
[ '0x5343056cdBeE51Ca53Ef059dF6111E43c4BdeC1A', {} ]
JSON-RPC Request Error:  signer_hideAccount
{ code: -32602, message: 'Corrupted input parameters' }
[ '0xFFDECDa3Eed4e9b9a6C7c45a7BEa675B4AA59F7E', {} ]
JSON-RPC Request Error:  signer_signTransaction
{
  code: -32602,
  message: 'Invalid data format: Required chain name or chain id parameter'
}
[
  {
    from: '0xd77CECbBED6c6EaD5b6A7EaDDFBDa4A3a780A9B0',
    to: '0xDaAC7bc5cDa4DAFDfdc8040847cedBb8bedbBAb1',
    gas: '0x3AE4B6bD4',
    gasPrice: '0xBa5',
    nonce: '0x9Dd682563E'
  },
  'dolore consequat dolore ipsum nisi',
  {}
]
JSON-RPC Request Error:  signer_importAccount
{
  code: -32602,
  message: 'Invalid data format: Required chain name or chain id parameter'
}
[ {}, {} ]
Success:  signer_generateMnemonic
JSON-RPC Request Error:  signer_sign
{
  code: -32602,
  message: 'Invalid data format: Required chain name or chain id parameter'
}
[
  '0xD5f76',
  '0xf8305EBD6D2e7Ff2FBCD4f56A2FDa3CedEDfb6e1',
  'aute aliqua esse',
  {}
]
JSON-RPC Request Error:  signer_exportAccount
{ code: -32602, message: 'Corrupted input parameters' }
[ '0xdd05fAD3405c5FAFC9D09B3CB45d6fa16CBf2204', {} ]
==========
Success:  1
Errors:  8
==========

Refactor to replace emerald-rs crate for a jade-rs

Summary:
The jade-rpc-signer server and client are out of sync. This is because jade signer doesn't use the generated rust typings from typings to support the RPC interface.

Motivation:
Because the project is out of sync with the rpc document, some of the request don't line up with the document descrption. Fixing this will mean that document updates accurately reflect the state of the service.

Acceptance Criteria:
Jade Signer supports generated typings.

ChainID is limited to u8 , which prevents us from supporting the broader > 255 chainID numbers that are probably more commonly used for sidechain/private networks .

This requires refactoring code signing to support this

A few of the parameter specifications for Jade signer in the openRPC document are incorrect and require an update.

Acceptance Criteria:
The open-rpc document should be able to generate a valid client for both typescript and rust.

this gets us out of libusb as a dependency. as well as splits up the signing to only have jade-signer be a signer, Ledger can be another service that is run in the future if we need that support.