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

Cosmos Hub Chain Name Service discussion #291

Open
hxrts opened this issue Apr 22, 2022 · 11 comments
Open

Cosmos Hub Chain Name Service discussion #291

hxrts opened this issue Apr 22, 2022 · 11 comments

Comments

@hxrts
Copy link
Contributor

hxrts commented Apr 22, 2022

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

@hxrts
Copy link
Contributor Author

hxrts commented May 6, 2022

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
Copy link
Contributor

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
Copy link
Contributor

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

@hxrts
Copy link
Contributor Author

hxrts commented May 8, 2022

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

@tombeynon
Copy link
Contributor

@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
Copy link
Contributor Author

hxrts commented May 9, 2022

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
Copy link

Goochie commented May 23, 2022

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

selectChain

@hxrts hxrts changed the title Cosmos Chain Name Service discussion Cosmos Hub Chain Name Service discussion May 24, 2022
@hxrts
Copy link
Contributor Author

hxrts commented May 24, 2022

Chain logo was just added to the asset Schema #370

Also off topic though.

@Goochie
Copy link

Goochie commented May 24, 2022

@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
Copy link
Contributor

@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
Copy link

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.

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

No branches or pull requests

5 participants