DRY the registry

[ligi]

In general I really like the project. One thing I dislike: currently this registry is duplicating data from https://github.com/ethereum-lists/chains this makes things very WET - and I like the DRY approach way more. This will e.g. become a problem when there is a new chain or an update to ethereum-lists/chains - then things start to become messy. I rather think the interchain-registry should become an aggregator and consume data from e.g. ethereum-lists/chains and enrich it e.g. with the eip155 prefix for the ethereum chains. What do you think?

[pedrouid]

Agreed, we could also create a cosmos-registry repo that could be used to feed into this registry. This way all data would be consumed externally and organized accordingly to the standard we define in this repo.

@webmaster128 what do you think about having a CI maintaining this repo from two external repositories?

[webmaster128]

Interesting question. Since I'm not too much into the Ethereum community, I don't know how habits are really. Sync would work either way: from here to ethereum-lists or from ethereum-lists to here – or even both ways. Implementing such a sync is probably a nice fun task and doable in any way we like. So I'd start with discussing the desired flow instead of the implementation.

Regarding CI: I'd be very careful with giving a CI write access to the repo. It could be done but I think having a small sync script that is run by a maintainer and created a diff for a PR would do the job. There is not a new Ethereum network every day, right?

Regarding cosmos: I would avoid spreading data over more places than strictly necessary. If we can collect them here, this should be nice and simple.

[ligi]

I think syncing both ways is too much overhead. There should be only one way syncing. And IMHO the sync should be from ethereum-lists/chains to this registry. I really think this project should just be an aggregation to prevent the need for syncing 2 ways.

[webmaster128]

Fine for me. Let's build an ethereum-lists importer then.

I see this as a second step after shaping the data format we want to have here.

[RiccardoM]

I think the best way to address this issue would be:

1. Create another repo, maybe called cosmos-chains inside the UCRegistry organization.
2. Use this repo simply as an aggregator of ethereum-lists/chains and ucregistry/cosmos-chains

This way we could have a CI that reads both lists, converts them into the appropriate format and simply writes them into this repo accordingly to how it is supposed to be.

This way in the future in order to integrate another chain specification we would simply have to:

1. Create another repo for that chain
2. Create a converter from that chain specification and update the CI

This would be the best approach to ensure high extendibility towards future standards. What do you guys think?

[ligi]

@RiccardoM I think this is exactly the way to go

[romeo4934]

@ligi @RiccardoM I can try to work on this issue. Any idea how should I create this converter that will take ethereum-lists/chains and put it here?

[RiccardoM]

@antoineherzog I think a good way to go would be:

1. Create the above mentioned cosmos-chains repo inside the UCRegistry organization.
2. Move all the currently here present Cosmos chain definitions there, removing the obsolete ones.
3. Create the aggregator.

Aggregator

Talking about the aggregator, I would start by using the GitHub APIs.

The aggregator could simply be a script that:

1. Reads the contents from a repo using the Get Contents API.
2. Transforms such contents if needed.
3. Pushes the transformed data to this repo, using the Create or Upload file API

These 3 points should be done for the UCRegistry/cosmos-chains and ethereum-list/chains repos.

[romeo4934]

Thank you Riccardo, it is crystal clear! I will work on that this week! @RiccardoM