Cosmos Hub Chain Name Service discussion

[hxrts]

Still early, but we can use this issue as a place to aggregate architectural notes and user requirements.

[hxrts]

At present we know relayers are using this repo. I believe Keplr is also planning to integrate. Are there other known users we should be speaking to?

[TrevorJTClarke]

Hi - would this be possible to track features? (Chain supports permissioned or permissionless cosmwasm for example).
We started using this for helping some tools, and it would be awesome if there was a way to load all chain configs or filter to chains meeting certain feature or other criteria.

[TrevorJTClarke]

Could also turn on the "discussions" feature in git repo ;)

[hxrts]

Seems a little off topic. Maybe make a new issue for this? Agree this info could be useful.

[tombeynon]

@hxrts love the idea of a Chain Name Service. I recently built restake.app and cosmos.directory, the latter is built around the Chain Registry and provides live APIs making it easy to use this data in web applications. REStake then uses cosmos.directory for all interchain config. I also built most of Cosmos Omnibus which again relies heavily on Chain Registry.

I'm very interested in the outcome of the chain name service and would love to help out where I can if needed.

[hxrts]

thanks for your interest @tombeynon! what we need most right now is a better understanding of how an on-chain chain name + metadata directory might be used. if you have specific ideas please share!

[Goochie]

Hi, simple UI dev here - i have gone through the various api's and i have a quick question, which one is best suited to return me chain info and a URL to an icon for the chain ?

To provide some context i a have POC i am currently working on and i want to provide a menu not to dis similar to the mint scan menu, so i need chain info and the logo.. see an example below

[hxrts]

Chain logo was just added to the asset Schema #370

Also off topic though.

[Goochie]

@hxrts love the idea of a Chain Name Service. I recently built restake.app and cosmos.directory, the latter is built around the Chain Registry and provides live APIs making it easy to use this data in web applications. REStake then uses cosmos.directory for all interchain config. I also built most of Cosmos Omnibus which again relies heavily on Chain Registry.

I'm very interested in the outcome of the chain name service and would love to help out where I can if needed.

@hxrts Apologies for being a little off topic so which api would you suggest to use?

As an example i could use the following request and the response will hav e the chain logo (when its next updated)

https://cosmos-chain.directory/chains/arkh

also question to @tombeynon - i have had a look at the cosmos.directory - where can i get info on the api's you mentioned, also the restake app is a very cool app ...

[tombeynon]

@Goochie you can see a high level overview of the APIs available on the cosmos.directory Github: https://github.com/eco-stake/cosmos-directory. They've evolved a bit from there but it's easy enough to check what's being returned.

@hxrts personally chain registry really provides everything I need; so an on-chain version of that would be amazing. Biggest concerns would be how to keep it updated in a reliable and fast manner, e.g. gov proposals are great but don't move super quickly, and there are times where updates to Chain Registry are needed quite quickly (chain ID changes etc). I imagine allowing gov to vote on wallet addresses that are allowed to update each chain is enough, then those wallet addresses can make updates as often as required. Similar to Regen's carbon credit authorities.

Otherwise, all cosmos.directory does is provide the chain registry data directly, and decorate it with extra attributes to make integrating UIs easier. I maintain the Validator Registry which is very similar to Chain Reg but for validator attributes, so whatever happens with Chain Name service, would be interesting to see how it could apply to Val Reg too. Again cosmos.directory exposes this data in API form, and decorates with on-chain data, keybase images etc etc.

I'm not sure we'll avoid some middleware like cosmos.directory entirely, but making the Chain updates more permissionless/crypto native is definitely something I'm on board with.

Apologies for the slow reply, will try to keep on top of this conversation.

[HerbaFineLife]

En büyük endişeler, bunun güvenilir ve hızlı bir şekilde nasıl güncel tutulacağıdır; örneğin, gov teklifleri harikadır ancak çok hızlı ilerlemezler ve Zincir Kayıt'ta güncellemelerin oldukça hızlı bir şekilde gerekli olduğu zamanlar vardır. Hükümetin her zinciri güncellemesine izin verilen cüzdan adreslerine oy vermesine izin verilmesinin yeterli olduğunu, ardından bu cüzdan adreslerinin gerektiği sıklıkta güncelleme yapabileceğini düşünüyorum.