Add light client support for test networks of Westend and Rococo

[wirednkod]

This PR adds light client support to the front end template.
Support is given only for our test networks of Westend and Rococo in order to avoid any possible mistakes that a user may act on, on live networks of Polkadot, or Kusama;
Defaults to local;

[nuke-web3]

While this is cool, I think it's misplaced here. the FE template is a bare bones demo to talk to a dev node almost exclusively.

I expect p.js to be used for any testnet operations, that is what the devhub docs suggests in almost all cases. Plus afaik this repo is unmaintained, perhaps mostly unused. Thus I see no real benefit in trying to revive it... unless that is the plan? If so how does this integration fit into that plan?

[kianenigma]

I kinda also see the issue here. In order to demonstrate the light-client-first approach, we can't just show the process of connecting to Kusama or another live chain. What we ideally need is a process to demonstrate how you can connect to your custom chain via light clients. I am not sure about the steps needed to achieve that.

[wirednkod]

My initial approach (connecting to westend/rococo) was for a user to have a simple ui interface to test against a node without the need of a local node. Another addition that can be added is for the user to pass through an input spec to the desired chainspec and allow to connect to the local node through a light client. If that is something that sounds a positive step forward, I can proceed with the implementation (and some how-to around it)

[kianenigma]

user to have a simple ui interface to test against

Imagine if I am writing my own blockchain, I will want to test against my blockchain's light client node, not westend. This is what we have to document.

[wirednkod]

For this to work - one needs to provide the chainspec of the custom/local chainspec. There are some ways for this to happen, but I do not think a web-page-tutorial or chainspec-uploader would do the job.
Meaning, someone needs to provide the local-node chainspec to the light client, in order to init it - but light client adds the chain based on the code included in the page.. I can think maybe of some way to "save the spec" in the localstorage etc etc, but the possible errors I can think of are many - e.g. chainspec format is wrong, bootnodes are missing, websocket is not secure (wss) etc etc

[kianenigma]

For this to work - one needs to provide the chainspec of the custom/local chainspec. There are some ways for this to happen, but I do not think a web-page-tutorial or chainspec-uploader would do the job.

Is there any tutorial around this somewhere?

[wirednkod]

For this to work - one needs to provide the chainspec of the custom/local chainspec. There are some ways for this to happen, but I do not think a web-page-tutorial or chainspec-uploader would do the job.

Is there any tutorial around this somewhere?

Yes - look at the section : Use the RPC provider to connect to a custom network

The custom/local spec (jsonCustomSpec.json) is imported, then the Substrate Connect provider is created :

// Create the provider for the custom chain
const customSpec = JSON.stringify(jsonCustomSpec);
const provider = new ScProvider(customSpec);

... connected... :

// Stablish the connection (and catch possible errors)
await provider.connect();

and creates/returns the api that dApp can communicate with the network, through light client:

const api = await ApiPromise.create({ provider });

[kianenigma]

Thanks for the explanation Nikos. I agree that this is not super useful then. What seems to be needed is the "chain-spec-uploader" or something similar.

The scenario is this: You run substrate-node-template, which has a very well known chain spec that we can easily store in place. Then you launch this template and there should be an easy way for you to feed the chain spec of your custom chain here and connect to it.

[wirednkod]

Not exactly. When the node starts it produces a bootnode that needs to be added to the chainspec. Thus we cannot have it "pre-saved". What we can do is require (provid8ng step by step instructions on how to) from the user to generate the chainspec with the bootnode and upload it to the page. This will be saved on the localstorage of the browser and initiate the light client for that chainspec (which should be the one the user started locally). Again the errors that light client can produce are numerous based on user erroneous input, but the above is something feasible. What do you think?