Parity-ethereum: Feature Request: specify custom chain spec at remote location

[stone212]

A feature request. Currently you can specify a custom chain spec with:

$ parity --chain /path/to/chain-spec.json

The request is to allow:

$ parity --chain http://aws-for-example.com/chain-spec.json

[5chdn]

Just wget it :)

wget http://aws-for-example.com/chain-spec.json
parity --chain chain-spec.json

[stone212]

That misses the point. The idea is to have the file available from one remote/central location. I know Parity doesn't do that now, which is why this is a feature request. You keep finding corner cases where what I stated is a problem is not actually a problem, and then instead of fixing the problem your solution is for the user to modify his actions. LIke telling a doctor it hurts when you sleep on your side, and he says "don't sleep on your side". I posted a new issue where I made the reason for the feature request clear.

[rphmeier]

I don't see why Parity should support fetching of the chain spec. IMO it's beyond the scope of the software (which is just to interpret the spec and run a corresponding node). It would be simpler to configure your node deployment (docker images or w/e) to be bundled with the chain spec or to write a wrapper script that fetches it.

[tjayrush]

@stone212 I think the idea is to use the Linux design philosophy. If there's already excellent facility to do what you want to do outside the software (i.e. wget), use that as opposed to loading down the software with another feature.

[stone212]

@tjayrush Ironically I think the very reason for my suggestion is the Linux design philosophy. Because now, Parity includes several chain spec files in it by default and so Parity has a choice. Either continue to add chain specs for every well-ish-known ethereum-like blockchain, or add this feature which allows people to specify which chain spec to read from.

You also made the suggestion of using wget as a few other people have. Wget does something completely different, and in this case it would not be a useful solution. The goal is to have the chain spec live remotely so it can be changed in one location. Wget is a solution to acquire the chain spec, which is not something I consider to be lacking in the current implementation.

Of course if people don't see the value then the request may be rejected but I appreciate that you're actually taking it seriously. Thank you.

[stone212]

@rphmeier

It would be simpler to configure your node deployment (docker images or w/e) to be bundled with the chain spec or to write a wrapper script that fetches it.

To take this seriously would imply that instead of a small change to Parity, the entire way that one deploys a private blockchain should be limited to using "docker images or w/e". That is never a good thing, and it's especially bad because it either assumes that only one team will be deploying nodes, or that end users who want to add their node to a particular private blockchain must have the ability to support this limited set of deployment options.

About writing a script that fetches the chain spec: You are making the mistake that so many other people are making, which is to think that the goal is to acquire the chain spec. That is not something that is currently lacking, and it has nothing to do with the request.

The request is for Parity to be able to read (not copy!) a remote chain spec. That would meant that the chain spec can be changed remotely.

Note that this is not necessary with expanse, mainnet, or any other chain that Partity has built-in because these are updated with the latest release. But unless Parity wants to continue to add chain spec files for all commin public chains, my request allows for forks within these chains.

But anyway I appreciate that you replied and gave it some thought. If the request is rejected, that's how it goes. It was still worth making.