Add a ibc.json file in the root directory

[nooomski]

We should create an ibc.json file in the root directory that contains all the preferred channels, non preferred channels and a trust hash

As a rough idea:

"cosmos": { // should be unique chain identifier
    "trust_hash": "" // some hash
        "osmosis": { // also unique chain identifier
            "preferred_channel": "141-0",
            "non_preferred_channels": [
                "189-23",
                "123-456",
                //etc..
            ]
        },
        "akash": {
            "preferred_channel": "184-17",
            "non_preferred_channels": [
                //etc..
            ]
       }
       // Repeat for each chain that has an IBC connection
// Repeat for each chain

Not sure what's the best way to notate those channels. @sunnya97 @jackzampolin ?

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

[sunnya97]

What exactly is a trust hash in this case?

[nooomski]

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

[sunnya97]

@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?

[sunnya97]

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

[jackzampolin]

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

[jackzampolin]

@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

[jackzampolin]

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.

[nooomski]

@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.

[jackzampolin]

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

[nooomski]

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.

[sunnya97]

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

[sunnya97]

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

[nooomski]

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

[jtieri]

@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

[nooomski]

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

[adizere]

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.

[JeremyParish69]

It has been agreed upon how to handle IBC data in https://github.com/cosmos/chain-registry/pull/379