feat: add @streamr/config package

[kare]

No description provided.

[linear]

ETH-184 Config package

The scripts should output config file, and that config file should go to NPM. This eliminates hand-copying addresses everywhere else.

This config package should live in network-contracts monorepo.

Config package structure should reflect multi-chain thinking: no more "main chain <> side chain" but just chains that are self-contained and maybe talk to each other over bridges or smth:

{
  "mainnet": { ... },
  "xdai": { ... },
  "dev_mainnet": { ... },
  "dev_xdai": { ... },
  "polygon": { ... },
  ...
}

Fundamentally the idea is to automate this google docs sheet: https://docs.google.com/document/d/1tygb8_9Y5AmzHzio3s3lM0rw_APGFT9hnNNutpUjO8c/edit#heading=h.6ynmi29odip

It will be the 3rd iteration on this config package idea, two previous iterations being:

• https://www.npmjs.com/package/data-union-config that lives in data-union monorepo, manually updated
• https://www.npmjs.com/package/streamr-dev-config that is generated by smart-contracts-init repo half-automagically

So ideally it:

• contains all "static configuration data" from production chains, manually updated
• mixed with dev environment chains, automatically updated by the smart-contracts-init
  • hence it will be useful that smart-contracts-init and this config package live in the same monorepo, the network-contracts
• is used by every streamr package everywhere that needs "static configuration data" (most of them), and no one needs to hand-copy things redundantly to different places again, also we can retire that google doc sheet.

[jtakalai]

Very nice! Let's get this into use. One very specific use case would be having streamr-client ingest a Network definition (or two, "mainnet" and "sidechain") and find everything it needs from there. That would already be a big win for maintainability.

[hpihkala]

@jtakalai @kare can we add to this:

• Public/default RPC urls for each chain
• The contracts recently deployed to Polygon
• README changes describing how to use

And get it merged?

[jtakalai]

Good to get a first version out, so better merge it.

Things to think about though:

• is the idea the we have a prod that mirrors dev? In that case the chain names should be precisely the same
• or maybe we could just have them all side-by-side in the same structure, with an extra "testnet" attribute or something? This way they could all be "potentially available" in e.g. tests that for some reason want to read things from live network (or later in some kind of UI selector?). From technical point of view it wouldn't hurt really if we assume we're going to pick a chain by name anyway when we need one.

[samt1803]

streamRegistry and streamStorageRegistry could be added here

[samt1803]

the storagenoderegistry is also wrong: current values for the docker dev env sidechain are:
streamRegistryChainAddress: '0x6cCdd5d866ea766f6DF5965aA98DeCCD629ff222',
nodeRegistryChainAddress: '0x231b810D98702782963472e1D60a25496999E75D',
streamStorageRegistryChainAddress: '0xd04af489677001444280366Dd0885B03dAaDe71D',

[hpihkala]

Please let's avoid using only "nodeRegistry" as any config variable. The NodeRegistry contract is instantiated for a few different purposes. Let's use names that describe the instance (not the class):

• storageNodeRegistry
• trackerRegistry

[samt1803]

Looks good!

[samt1803]

Local docker dev env sidechain address is wrong and 2 other can be added there.
Rest looks good, verified all matic addresses.

[samt1803]

the storagenoderegistry is also wrong: current values for the docker dev env sidechain are:
streamRegistryChainAddress: '0x6cCdd5d866ea766f6DF5965aA98DeCCD629ff222',
nodeRegistryChainAddress: '0x231b810D98702782963472e1D60a25496999E75D',
streamStorageRegistryChainAddress: '0xd04af489677001444280366Dd0885B03dAaDe71D',

[hpihkala]

• is the idea the we have a prod that mirrors dev? In that case the chain names should be precisely the same

Nah I dont't think that needs to (or even should) be the goal.

• or maybe we could just have them all side-by-side in the same structure, with an extra "testnet" attribute or something? This way they could all be "potentially available" in e.g. tests that for some reason want to read things from live network (or later in some kind of UI selector?). From technical point of view it wouldn't hurt really if we assume we're going to pick a chain by name anyway when we need one.

Exactly, they can very well be all defined in the same file. Apps can then depending on their environment say "use this, this and this chain", referring to the chains by name. So on app side config would then start to look something like this (example, not literal):

In local docker:

marketplaceChain=local-mainchain
dataUnionChain=local-sidechain
streamChain=local-sidechain

In prod:

marketplaceChain=ethereum
dataUnionChain=xdai
streamChain=polygon

Later on in a multi-chain setup we can give lists:

marketplaceChains=ethereum,xdai,polygon
dataUnionChains=xdai,polygon
streamChain=xdai,polygon