Field "chain" is used twice with different meaning/definition

[kopeboy]

I would clarify what does "chain" mean, given that we have "parent.chain" that has a different definition.
Since the latter is dependent on / specific to this repository and doesn't have a correspondence on a on-chain value (EIPs are off-chain right?), I would consolidate to the former and make a clear definition of what is it.
There are irregularities currently on the "chain" field values, examples:

• Capitalized/UPPERCASE/lowercase (ETH/ETH vs Evmos/evmos)
• equal to the symbol of the native currency vs. to the name or shortname of the chain (ETH vs Solana vs evmos)
• is it a unique representation of the parent chain or parent native currency (by slip44 maybe?)? Seems so with children of Ethereum but not otherwise, like Aurora-NEAR, Avalanche-AVAX, etc..

In general, I would add comments to
https://github.com/ethereum-lists/chains/blob/master/model/src/main/kotlin/org/ethereum/lists/chains/model/Chain.kt
to help listers provide consistent values.

[ligi]

true - this is inconsistent
I think we just remove the "chain" in the root and keep it in parent
"chain" in the root is kinda redundant to "name" anyway

[ligi]

migration path:

• we remove it in all files from _data
• the processor adds it again for the legacy API
• in API v2 it is not added (API v2  #1889)

[kopeboy]

Excuse me? How would I index to the parent chain if the value of "parent.chain" is NOT on the parent?!
Either you add a field holding the "EIP155-X" like values at the higher level,
OR you define the parent.chain by an existing identifier for the chain, like chainID or shortname..

[ligi]

the filename is CAIP2 and the values of chain fields in parent is CAIP2

[kopeboy]

They would need to be "eip155:1" instead of "eip155-1" for CAIP2.
Anyway, why would you want someone to parse github folders for file names when you can have everything in a single json that is already the list? Can't we override either "chain" or "parent.chain" with the same chosen id to make the list file sufficient?

[95HenryFong95]

from the feedback have you like that we need to do the old behind and welcome new