Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/information / metadata proposal #14357

Closed
Reecepbcups opened this issue Dec 19, 2022 · 11 comments
Closed

x/information / metadata proposal #14357

Reecepbcups opened this issue Dec 19, 2022 · 11 comments

Comments

@Reecepbcups
Copy link
Member

Reecepbcups commented Dec 19, 2022

Summary

This issue proposes a new module, x/information (or x/metadata).
It would provide chain official accounts, websites, support, and images for frontends and cosmos directory.

  • Twitter accounts, facebook, website, git_repo, images, network_type, node_home, explorers (kind, url, tx_page?).

  • coingecko id

  • genesis_url

  • Also could add the constitution text here?

  • "other" key for an array of other values chain specific

  • other keys in cosmos directory

Problem Definition

By adding this, all chains can provide verifiable data for official accounts maintained by the chain itself. By adding it to the SDK, all future chains will ensure to have it. Using CosmWasm would be easier, but not all chains use. So this is the next option.

There are no downsides to this proposal than development time, which I (reece) am happy to take lead on.

Proposal

The x/information module would be similar to gaia globalfees. No keeper, only genesis params (gov & upgrade set). Then anyone can query. We should not use IPFS for anything except maybe the constitution.

Example WIP PR: https://github.com/cosmos/cosmos-sdk/pull/14361

@julienrbrt
Copy link
Member

julienrbrt commented Dec 19, 2022

related: #14065

Imho, a metadata module makes sense, however, what details should it contain? Should it be enforced by the SDK (in terms of available fields), or free to set by the chains?

If it there is no guideline, I don't see how frontends could take advantage of that if all chains have their format.

If we enforce it, and it is stored on IPFS like gov and group metadata, then making a module for one field in the genesis seems a bit overkilled.

@Reecepbcups
Copy link
Member Author

@julienrbrt Yea x/metadata would be a better name for this.

I think it would be best to have default set fields (as outlined above) which all frontends need & chains have.

Then have an "extra" array of objects for their chain specific data / links if they so want

I feel It’s better to store in the genesis directory than via IPFS links so users can easy query without ipfs re-query hassle.

@Reecepbcups Reecepbcups changed the title x/information proposal x/information / metadata proposal Dec 19, 2022
@iramiller
Copy link
Contributor

This isn't really the place for this larger discussion ... but as it applies here I want to point out that adding a new module can conflict with other existing modules that other chains may have ... Provenance has had a metadata module for some time now and adding a new one to the sdk which assumes KV store module names, etc are all unique and will not collide is going to be an issue here.

@minxylynx
Copy link

I second not relying on IPFS links so heavily.

@derekadams
Copy link

derekadams commented Dec 19, 2022

A possible method of addressing the issue @iramiller mentioned above is to add a provider field to module declarations and use that as part of the kvdb keys (e.g. all core modules have cosmos as provider). That way multiple x/metadata modules could coexist across multiple providers without conflict. Seems like this will become a common issue as the ecosystem expands and more core modules are added. This would also provide a method of programmatically differentiating between core modules and those contributed by other chains.

@pyramation
Copy link
Contributor

Should it be enforced by the SDK (in terms of available fields), or free to set by the chains?

If it there is no guideline, I don't see how frontends could take advantage of that if all chains have their format.

On the ability to add arbitrary fields... as long as it doesn't break RPC decoders can handle the decoding on clients

@testinginprod
Copy link
Contributor

testinginprod commented Dec 20, 2022

I don't think the feature set the module is covering justifies its existence, and hence maintenance burden, as a module in the SDK.

I'd be open though to consider metadata as a feature extension of some already-existing module.

@alexanderbez
Copy link
Contributor

We have https://github.com/cosmos/chain-registry/ for exactly this case. I'm not convinced this needs to exist on-chain.

@pyramation
Copy link
Contributor

We have https://github.com/cosmos/chain-registry/ for exactly this case. I'm not convinced this needs to exist on-chain.

Fair point. I suppose I can see a case for both sides. I think if it does happen, it should involve chain-registry types and have some cohesion between the two.

@tac0turtle
Copy link
Member

lets see about adding this to an exiting module.

I can see it being added to gov simply, In the future when base app/framework becomes stateful this sort of data could live there.

@tac0turtle tac0turtle closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 2024
@julienrbrt
Copy link
Member

julienrbrt commented Oct 1, 2024

Due to the lack of demand, we won't add this module or this functionality.
Unrelated but we've added metadata for validators (#21315)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants