Key provider

[graup]

Herajs itself will likely not have built-in local key management. At the moment it defers that to the aergo server, but it might be useful to be able to connect other "keychain providers". I will update this issue with details later.

[graup]

Also refer to https://github.com/aergoio/herajs-crypto which has functions to create/import keys and sign without talking to the server

[graup]

Just some thoughts. Eventually I'd like to have an API like this

const aergo = new AergoClient();
aergo.use(new FooBarKeyManager());
const txhash = await aergo.accounts.sendTransaction({ from: ..., ... })

where use() can add any sort of provider (plugin? strategy? manager? middleware? not to be confused with transport providers like Grpc)), and then sendTransaction asks all providers that implement sign to sign from the specified address.

Users could also provide their own, e.g.

aergo.use({
  sign(tx) {
    return someOtherKey.sign(tx);
  }
});

but maybe it should be higher-level than sign, e.g. getKeyForAddress()..? Or there can be a default provider that implements all of these and users can override them at any level they want.

Then @herajs/local-key-provider could offer a LocalKeyProvider() that implements local storage and signing using @herajs/crypto.

The provider could also override create methods maybe, so that the current server-based create implementation is just one default.

Can also use that to share transport providers.

window.aergoProvider = {
  client: new GrpcWebProvider({url: ...})
}
aergo.use(window.aergoProvider)

[graup]

Would be a good opportunity to simplify the API further and make the typing more consistent. I'm thinking

AergoClient {
  getChain() -> ChainState
  getTransaction(Hash) -> Tx
  getBlock(Hash|number) -> Block
  getBlockHeaders(options) -> BlockHeader[]
  getState(Address) -> AccountState
  getVoteResult(number) -> VoteResult
  getTransactionReceipt(Hash) -> TxReceipt
  getABI(Address) -> AbiDefinition
  getPeers() -> Peer[]
  queryContract(FunctionCall) -> FunctionCallResult
  callContract(FunctionCall, txParams) -> FunctionCallResult
  sendSignedTransaction(Tx) -> Hash
  accounts {
    create(password) -> Address
    list() -> Address[]
    unlock(Address) -> Address
    lock(Address) -> Address
    export(Address) -> ExportFormat
    import(ExportFormat) -> Address
    sendTransaction(Tx) -> Hash
    signTransaction(Tx) -> Signature
  }
}

and then internally they can go through the server, client, or somewhere else, depending on the middleware setup. e.g. client.accounts.create -> crypto.createIdentity() -> saveToLocalStorage() -> return address or client.accounts.create -> grpc createAccount -> return address.
For backwards compatability the default implementation can be the current one (going through the grpc client for everything).