frumioj
commented
2 years ago - Signing
lens/client/tx.go -> cosmos-sdk/client/tx/tx.go
-> cosmos-sdk/crypto/keyring
- Adding a key
lens/cmd/keys.go -> lens/client/keys.go -> cosmos-sdk/crypto/keyring
Looks to me like keystone client should replace the code that is in cosmos-sdk/crypto/keyring, adding any necessary functions not in keystone already (related to bc-specific addresses).
Note: AFAICT, there appear to be explicit dependencies in lens and cosmos for "local" (file-based) keys, despite the possibility of non-file backends being otherwise in use - am I misunderstanding these things?
For example, what does NewLocalRecord/writeLocalKey do if there is not a file-based keyring in use?:
And why is there a local directory assumed in the lens/client/chain_client.go?
ccc.KeyDirectory = keysDir(homepath, ccc.ChainID)
Neither of these assumptions should be made for a keystone key, since the private key bytes are not going to be in a file accessible in this way to the client code.
Current sign flow:
Signcall inlensfor all transactionstxFactory.SignmethodKeybaseimplementationDesired direction:
gRPC/protobufinterface such that all keyring backends aregRPCclient/server interactions. This allows for a much more extensible key signing interface and will allow us to integrate crypto libraries from other languages and architectures much more easily.Keyringserver should support client implementations via plugins that are installed in the~/.lensdirectory, or some other method of management. Need to ensure easy configuration for client developers as we build this integration.SignAPI doesn't depend on having the key bytes available on the client side. This is a better fit with ledgers and HSMs. We can create a seperate interface that includes the CRUD commands for adding and generating new keys that has NoOps for backends that don't support these operations.