Add projectName and projectShortName fields

[tsutsu]

Right now, there is no explicit, non-heuristic way to distinguish which chains are part of the same "project" or "system of networks" (i.e. which chains are "siblings" — maintained by the same community, run by the same validators, etc.)

I want to be able to look at e.g. ETH Mainnet, Ropsten, Kovan, Rinkeby, and Görli, and be able to automatically determine "those are all Ethereum"; and then look at e.g. ETC Mainnet, Kotti, Morden, and Mordor, and be able to automatically determine "those are all Ethereum Classic." I want to be able to build hierarchical navigation logic where you can first pick a project, and then pick a network/chain "of" that project. Right now, doing this requires that I manually scrub and enrich the chains.json data, which kind of betrays the principle of having this data all already available and fetchable in machine-readable form.

• Theoretically, this is what networkId should mean. But that's a lost cause — because of all the pre-CHAINID chains that use distinct networkIds despite being part of the same project, networkId is basically meaningless at this point, except as machine-readable data to talk to some very old node software.

• Grouping by chainName doesn't really work (despite this seeming to be the purpose of the chainName field?) as there are separate projects that reuse a "parent" project's chainName, e.g. https://www.elastos.org/ and https://primusmoney.com both having a chainName of "ETH" despite not having any affiliation with Ethereum. (They're only "Ethereum" to the degree that they run on the same node software, as all EIP155 chains do.)

• Grouping by infoUrl almost works for this! but there are exceptions, e.g. Görli having its own separate infoUrl instead of pointing at https://ethereum.org.

What does ~basically work, is parsing the name field and dropping the words Testnet/Mainnet and anything that comes after them.

IMHO, it'd be very helpful if there was a field in each chain that effectively contained the "first part" of what the name field contains. In other words, a projectName. Unlike chainName, it'd be human-readable. Also unlike chainName, it'd actually work for grouping :)

Some additional thoughts:

• The "other part" of the name field could be put into its own field as well, maybe something like componentName or serviceName. Seemingly right now networkName is being used as a slug-ified representation of this information, but it'd be helpful to be able to get it in human-readable form. (Also, there's nothing forcing contributors to use networkName this way, so it has exceptions in it as well, e.g. chain-211 Freight Trust Network having a networkName of "freight & trade network". That's not even a slug!)

• The resulting projects data would be somewhat repetitive and hard to maintain. It might be easier to normalize it—i.e. break these fields out into files in a separate directory _data/projects, assigning each project its own (arbitrary) foreign-key sequential ID number, and updating the chains in _data/chains to reference the project they belong to by its ID. This file could contain:

  • a human-readable name
  • a shortName or slug
  • an infoUrl for the project itself
  • potentially, the chainId for the "primary" or "production" chain that the project's community's efforts are focused toward
  • potentially, a projectId that this project is a "forkOf" (e.g. in the case of Ethereum Classic)
  • potentially, a projectId for a "parent" or "umbrella" project, if this project isn't a fork (= no difference in community membership), but is a set of networks that both "belong to" a parent project while also being their own thing (as e.g. the ETH2.0 networks are to the greater ETH community/ecosystem.)

[ligi]

Thanks for your thoughts. Wondering what your use-case is

[tsutsu]

I work on https://www.covalenthq.com/; we provide APIs to run heavy analytics queries regarding individual addresses, whole wallets/portfolios, or entire networks/chains.

Right now a single chain is the "toplevel" of this hierarchy; but I'm currently working on expanding this so that you can ask analytics questions about a "system of networks" (e.g. aggregate usage/transaction volume, to know if there's any real engagement with a project on any of its networks.)

It'd be helpful for this, to have stable, agreed-upon identifiers (either an ID number or slug) to refer to systems-of-networks by; to be able to know which chains/networks belong to said systems-of-networks; to be able to know which network is the primary one (to use as a default when a system-of-networks is chosen); to be able to display the name of just the system-of-networks or just the individual network within the system-of-networks individually as breadcrumbs/picker options/chart labels/etc.

[tsutsu]

(I would also like other helpful stuff for display, like logo metadata for projects and/or chain-native currencies, similar to the logo metadata in https://github.com/ethereum-lists/tokens. But that's a bigger ask, since it'd require gathering new data rather than just refactoring existing data.)

[ligi]

Thanks for the info. I would be open to add a "project" field to correlate projects. Not a fan of different subdirs as I want to keep things backward compatible.
And yea we can add fields for logos too.