Hello,
I am working on hermes to implement an IBC connection between cosmos chain and a non-cosmos / non-tendermint-based chain.
For the sake of the explanation I will assume I have a GenBlockChain running a consensu protocol called GenBFT.
Configuration is then:

• cosmos network with tendermint consensus protocol, running an IBC GenBFT light client that can monitor and validate events happening in the GenBlockChain
• GenBlockChain with GenBFT consensus protocol running an IBC tendermint light client that can monitor and validate events happening in cosmos.

As far as I understand the ibc-relayer crate, the key trait that I have to implement is the ChainEndpoint.

I am studying the methods and the associated types that the trait has, and I realised there is something that does not seem consistent: I am referring to the associated type ChainEndpoint::ConsensusState, and the two methods ChainEndpoint::build_consensus_state and ChainEndpoint::proven_consensus_state.

If I define the ConsensusState type to be TendermintConsensusState I wouldn't be able to implement build_consensus_state as my side of ChainEndpoint does not have access to cosmos network and it wouldn't know anything about the current state of the tendermint consensus state, nor it should know anything about tendermint or cosmos (in terms of structs and functions) as this is the role of the CosmosSDKChainEndpoint implementation.

On the other hand, if I define ConsensusState to be the GenBFTConsensusState then I wouldn't be able to implement proven_consensus_state as, again, my ChainEndpoint does not have access to the cosmos network in order to request and prove the current state of the GenBFTLightClient running on cosmos.

I am clearly missing something from the code design POV, can you please help me out understanding how my GenBlockChainEndpoint should look like?