Comments (9)
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).
from chain-registry.
might need to give more detail on ics support to discover functionality like interchain accounts mauth
from chain-registry.
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...
from chain-registry.
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
from chain-registry.
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?
from chain-registry.
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
from chain-registry.
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
from chain-registry.
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 standardICS20-2
. If one ICS requires another ICS, the latter can be left out imo.We can consider skipping
ibc_enabled
and haveibc_go
be eitherfalse
or a specific version number like3.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.
from chain-registry.
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?
from chain-registry.
Related Issues (20)
- Wrong coingecko id for Liquid Staking Crescent token
- Validation Error logo_URIs HOT 1
- Proposal for changing structure of the repo HOT 1
- https://github.com/cosmos/chain-registry/blob/master/cronos/chain.json HOT 1
- non-chain binaries
- Proposal: have a list of chain upgrades along with the binaries used HOT 2
- Add Line network (LINK) to registry
- Add IBC denoms to assetlist.json HOT 2
- add IBC relayers to chain.json HOT 1
- how to future proof tendermint_version key? HOT 3
- duplicated tokens on chain-registry HOT 5
- Add required go version to chain.json HOT 1
- Fix low gas price to 0.0025 in osmosis HOT 1
- Chronic Chain seems to be dead. Can someone confirm? HOT 3
- Broken Links
- Add: Maya Protocol
- Create template for upgrade pull requests
- Duplicate `logo_URIs` field in `onomy` chain
- Set a License? HOT 4
- Link Checker Report
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chain-registry.