x/information / metadata proposal

[Reecepbcups]

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]

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]

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

[iramiller]

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]

I second not relying on IPFS links so heavily.

[derekadams]

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]

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

• would be great to have some field structure similar to https://github.com/cosmos/chain-registry
• some fields could be autogenerated by the software binary

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]

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]

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

[pyramation]

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]

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.

[julienrbrt]

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