ConnectionEnd in ICS does not have the "local" connection ID while it is included in cosmos-sdk implementations and the ConnectionEnd included in query responses (included in the protobuf definitions).
For channels, ChannelEnd in ICS matches the Channel in cosmos-sdk in the sense that "local" parameters (port-id and channel-id) are not included there. For queries that return multiple channels there is an IdentifiedChannel structure that includes the "local" parameters.
Also, should the queries for multiple channels and connections be required by standard and therefore documented in the ICS-es? This would be useful for the relayer :)
master
N/A - just looking at the code and specs
cc @cwgoes
I like the idea of defining what query functions TAO should support.
I think the relayer guide #6483 should probably outline what relayers can expect from the SDK IBC implementation
Hmm, strictly speaking, the connection end does not need to store the local connection ID since it is part of the key.
Is there a reason we need to store this in the SDK? If not, let's remove it.
probably convenience, I can take this change on
probably convenience, I can take this change on
Splendid, thanks. Just cleaner to avoiding duplicating data, I think.
For "query all connections" query, the id along ConnectionEnd is useful. For channels there is the IdentifiedChannel struct.
For "query all connections" query, the
idalongConnectionEndis useful. For channels there is theIdentifiedChannelstruct.
We can create an analogous IdentifiedConnection, I expect.
Most helpful comment
We can create an analogous
IdentifiedConnection, I expect.