Add a ibc.json file in the root directory about chain-registry HOT 17 CLOSED

Besides preferred channels we're good to get started on this, right? @jackzampolin how does legacy_channels sound to you?

from chain-registry.

What exactly is a trust hash in this case?

from chain-registry.

That would be the block header to prove from which chain data comes from, this was a suggestion by @jackzampolin

from chain-registry.

@nooomski I think that was independent; I believe that was for state sync

But I might be wrong, maybe relayers do need this

@jackzampolin can you confirm?

from chain-registry.

Resource to use: https://github.com/notional-labs/notional/blob/master/relaying-guide/rly/config.yaml

from chain-registry.

https://github.com/strangelove-ventures/relayer/tree/main/interchain

from chain-registry.

@sunnya97 relayers no longer need that but if they had it they could independently verify the veracity of the full node they are communicating with

from chain-registry.

I personally think the file hierarchy that @jtieri has in the interchain directory is the best way to store this info. We also don't need to store info on non-prefered channels.

from chain-registry.

@jackzampolin do you mean non-preferred channels? I think @sunnya97 made a good point that we need to specify these to keep them open while people remove tokens off these channels.

from chain-registry.

@nooomski afaik giving any kind of publicity to non-prefered channels will encourage usage. I don't think that information should be included

from chain-registry.

I see your point @jackzampolin . I'll let Sunny weigh in on this. Maybe we can schedule another call in the near term to go over this and make sure we can find agreement on some of the other issues as well :)

I know Adoriasoft wants to work on this and has some questions about some issues that I'd love to discuss with you both.

from chain-registry.

I feel we should still have something somewhere that lists the non-preferred channel, if only to send a heartbeat until people remove tokens form them? Cause would suck to have tokens lost that way

from chain-registry.

@jackzampolin which one is the interchain repo? I'll take a look at that

from chain-registry.

Maybe just changing the language to legacy_channels would be sufficient to discourage usage?

from chain-registry.

@sunnya97
we have aggregated canonical path and chain data here https://github.com/cosmos/relayer/tree/master/interchain

Most of this data came from https://mapofzones.com/zone?period=24&source=akashnet-2&tableOrderBy=success&tableOrderSort=desc&testnet=false, the Osmosis integrators TG group and the Notional config files previously linked aboove

from chain-registry.

Beside channels, on a longer-term basis, it might be ideal to include the following additional information relevant for IBC relayers:

• the connection and clients underlying a high-value channel
• preferred/max fees, denom name, slip44
• account prefix
• max_tx_size (depends on genesis file of the network)
• clock drift and max block time (for IBC clients, depends on the block frequency of the network)

Maybe just changing the language to legacy_channels would be sufficient to discourage usage?

+1

For the question of having a single/global IBC.json file versus per-chain file: Maintaining a file with hundreds of entries (currently there are ~20 IBC chains and 2 DEX-es, so ~80 channel ends) seems daunting, but not sure if there are other pro/con arguments for the global IBC.json file.

Currently not sure how to automatically populate these, but we need this file and start adding them manually at first.

For automation: an option is https://www.mintscan.io/cosmos/relayers -- either crawling the HTML here, or using the mintscan API, or partnering with the MintScan team to give us an API if there isn't a public one already.

from chain-registry.

It has been agreed upon how to handle IBC data in #379

from chain-registry.