relay_chain field in chain specifications should match the id of the relay chain

[tomaka]

You can for example right now start a collator with a chain specification that contains "relay_chain": "kusama".
Polkadot has four hardcoded relay chains: "polkadot", "kusama", "rococo", and "westend", and when a parachain collator is started, it connects to the relay chain found in the "relay_chain" field.

However the name "kusama" for example doesn't correspond to anything in the relay chain spec. The chain specification of Kusama contains "id": "ksmcc3", and not "kusama".
Similarly, Westend contains "westend2" and Rococo contains "rococo_v2_1".

Smoldot, on the other hand, doesn't have any relay chain hardcoded in its binary. It doesn't know what the word "Kusama" means.
When pass a parachain specification to smoldot, it looks into the "relay_chain" field, just like Cumulus does, but then tries to match this value with the "id" of a relay chain.
This mismatch creates some constant frustration, because in order to connect to a parachain with smoldot you need to take a parachain specification then modify the "relay_chain" field manually.

There are two solutions to this issue: either hardcode the four chains in smoldot's source code just like Polkadot does, which would clearly be a hack, or make the "relay_chain" field match the "id" of the relay chain in Polkadot/Cumulus.

I'm not advocating that running polkadot --chain kusama should stop working, just that the parachain chain specification should use the "id" of the relay chain. And for backwards compatibility we could still hardcode the four relay chains names but print a warning if they are used in a parachain spec.

[joepetrowski]

The chain specification of Kusama contains "id": "ksmcc3", and not "kusama".

Would it be possible to change ksmcc3 to kusama? "CC3" stands for "chain candidate 3", since indeed we did have to restart the network 3 times. Once balance transfers were enabled, however, the chain was no longer a candidate, it was "kusama".

[PierreBesson]

It's not operationally practical to change this id as it is used for the db folder on the node (eg. /$HOME/.local/share/polkadot/chains/ksmcc3/db/full). We could ask operators to rename their directory or do it with a "migration script" but this would have to be coordinated and introduce some risk of messing it up.

[dzmitry-lahoda]

imho long term if more ordinal users and browser dev will user smoldot it may be awesome they can bind chains by ids in specs.

cumulus people can migrate data.