client/chain_client: Add option to construct chain client with client.Client directly
#94
Conversation
| return err | ||
| } | ||
|
|
||
| // TODO: figure out how to deal with input or maybe just make all keyring backends test? |
There was a problem hiding this comment.
I think we should make all keyring backends test backends and eliminate the option from the struct
| } | ||
|
|
||
| func (cc *ChainClient) initKeybase() error { | ||
| // TODO: test key directory and return error if not created |
There was a problem hiding this comment.
would be nice to have options for in-mem keysbases too.
|
Hey @renaynay thanks for the PR, interested to hear what you are trying to do here and how to better support this. I can imagine how you might want to use this but would love a bit more clarity here and potentially some code 🙏 |
|
Hey @jackzampolin I'll provide some more code snippets later of how we plan to use the constructor. Just to tl;dr it - celestia-node has a bridge node type that maintains an rpc connection to a celestia-core(tendermint) client. We have two options: either dialling a remote endpoint handed to the node during construction or to embed the celestia-core node and use the provided client.Client rpc interface. Either way, it would be nice if the chain client constructor can take a client.Client instead of having to dial the given endpoint. |
Add option to construct
ChainClientwith an RPCclient.Clientdirectly.TODO: