Include a new category for IBC

[nooomski]

chain.json should include a category called ibc with at least the following:

• ibc_go_version
• ibc_enabled (true / false)
• supported_ics

[JeremyParish69]

I think this is a great idea, @nooomski

Regarding ibc_go_version, what would be provided if the chain isn't using ibc-go at all? would it just not be provided? Could this be changed to simply ibc_version? or does ibc have a different versioning cycle than ibc-go?

sounds to me like supported_ics makes the ibc_enabled boolean redundent. I don't see much point in mentioning the possible standards--only the enabled ones. Maybe it could be called something like enabled_ics to avoid confusion?

E.g., "ibc_go_version": "3.0.0" "ics_enabled: {"ics20-1","ics27-1"}

Should the listed standards just assume all the prerequisistes? (e.g., both 20 and 27 require both 25 and 26, and those in turn require many others).

[hxrts]

might need to give more detail on ics support to discover functionality like interchain accounts mauth

[JeremyParish69]

I'm not sure I follow. Are you saying, @hxrts , that there are still many possible feature subsets that may be permitted along with something like ics27, such that merely putting 'ics27' isn't enough to determine exactly what has been enabled?

Can that be pushed to a new issue breaking ics27 down further? For now, I don't know too much about ICA yet...

[hxrts]

yes exactly. feels like it's kind of important to consider the module/submodule structure in its entirety here, as that would impact how we want to structure capability fields in the metadata, no?

here's mauth for reference, which is split out into a separate module but doesn't have its own ics https://github.com/cosmos/gaia/tree/ica-acct-auth/x/mauth

[JeremyParish69]

yes exactly. feels like it's kind of important to consider the module/submodule structure in its entirety here, as that would impact how we want to structure capability fields in the metadata, no?

here's mauth for reference, which is split out into a separate module but doesn't have its own ics https://github.com/cosmos/gaia/tree/ica-acct-auth/x/mauth

Well, this 'mauth' module lives under 'gaia', not under 'ibc-go', so does it really apply? I wonder if including it could cause issues down the line, like if a program tries to look for mauth code in ibc-go but then cannot find it.

Still, I like this thinking, and if there are many different possible submodule/feature subsets, then I'm inclined to agree that we can allow for more separation.

Some questions:

Will all features necessarily belong 'under' some ics? e.g., it looks like mauth perhaps belongs under ics27. If so, we might be able to keep the term 'ics' in the name. -An alternative term could be 'apps', which includes things like 'transfer', 'ics-27', and '29-fee'. -Or another, more generic alternative could be 'modules', which can include core things like '02'client', '03-connection', '04-channel', etc. This could create a lot more work having to list them all, but also allows for specific subsets sets of core modules. I'm still thinking it'd be best to just assume all prerequisite modules for enabled apps are included.

Were you thinking something more like an object for each ics that could include submodules? like: "ics_enabled": { "ics27-1": {"mauth"}, "ics20-1":{} }

or maybe just allowing non-default submodules to be listed along with the ICS standards could work, as in: "ics_enabled": { "ics27-1", "mauth", "ics20-1" }

Thoughts?

[hxrts]

This is how the sdk will be specifying sdk module configs in the near future btw

https://github.com/cosmos/cosmos-sdk/blob/main/simapp/app.yaml

[nooomski]

I like the idea of sticking to 'apps' instead of ICS, but one problem that could emerge is if, say, two chains both support 'transfer', but one still using ICS20-1 and another is using some updated standard ICS20-2. If one ICS requires another ICS, the latter can be left out imo.

We can consider skipping ibc_enabled and have ibc_go be either false or a specific version number like 3.0.1. I would actually suggest the same for cosmwasm in #419

[JeremyParish69]

I like the idea of sticking to 'apps' instead of ICS, but one problem that could emerge is if, say, two chains both support 'transfer', but one still using ICS20-1 and another is using some updated standard ICS20-2. If one ICS requires another ICS, the latter can be left out imo.

We can consider skipping ibc_enabled and have ibc_go be either false or a specific version number like 3.0.1. I would actually suggest the same for cosmwasm in #419

Can we imply ICS20-1 vs ICS20-2 based on the IBC Go version? In the case, we could use something like 'transfer', but we'd also need both fields. However, could there ever be a case where we have an app or standard like 'transfer' or 'ICS20' but no IBC Go version specified?

I like the idea of using the version number field being doubled as the boolean.

[JeremyParish69]

This is how the sdk will be specifying sdk module configs in the near future btw

https://github.com/cosmos/cosmos-sdk/blob/main/simapp/app.yaml

I'm a little confused... how exactly can this inform the design. Should some list in here define some ics_app enumeration?