add wss bootnodes to statemine/t chainspec

[bernardoaraujor]

A tutorial on Substrate Connect is being added to the Substrate Developer Hub: polkadot-developers/substrate-docs#1122

It uses Statemint as example for Parachain, and a list of WebSocket-enabled bootnodes is necessary for Substrate Connect.

[NachoPal]

I am not very familiar with Substrate Connect, but I don't think Statemine/t production chain_spec.json should be changed for a tutorial.

[bernardoaraujor]

I am not very familiar with Substrate Connect, but I don't think Statemine/t production chain_spec.json should be changed for a tutorial.

@NachoPal We are making efforts to get more traction on Substrate Connect adoption, and adding documentation (tutorial) is one of the actions to make that happen. For any team that adds Light Client support for Statemint/e, they will need the chainspecs for those networks. These chainspecs need to list WebSocket enabled bootnodes. And these chainspecs need to come from a canonical source of truth that is publicly available.

It seems the current consensus is that the network source code is the source of truth for chainspecs, and github.com/paritytech/chainspecs is a mere convenience for internal Parity use only (paritytech/chainspecs#11). So the most reasonable place to list those bootnodes seems to be here.

@joepetrowski what are your thoughts?

[joepetrowski]

For any team that adds Light Client support for Statemint/e, they will need the chainspecs for those networks.

Fair enough. However, and perhaps I don't know enough about Substrate Connect, but doesn't the Relay Chain have all the header info of parachains? I.e., wouldn't a light client to the Relay Chain essentially give you a light client to every parachain? I don't understand the need to connect a light client to a parachain. Not to say I'm against it, I just don't see where you're going with this. When we talk about having 100+ parachains, telling users "run 100 light clients" seems like a bad story.

These chainspecs need to list WebSocket enabled bootnodes.

Are the current bootnodes not WS enabled? If not, why do the bootnodes need to be WS enabled in the first place? Couldn't the light client find another node in the network to use (after entering the network via "regular" bootnode)?

Has the devops team agreed to run these new bootnodes with the same uptime/availability guarantees as the other bootnodes?

[tomaka]

Fair enough. However, and perhaps I don't know enough about Substrate Connect, but doesn't the Relay Chain have all the header info of parachains? I.e., wouldn't a light client to the Relay Chain essentially give you a light client to every parachain? I don't understand the need to connect a light client to a parachain. Not to say I'm against it, I just don't see where you're going with this. When we talk about having 100+ parachains, telling users "run 100 light clients" seems like a bad story.

A light client can know a parachain's headers just by connecting to the relay chain, however knowing the headers isn't very useful. In order to access the parachain's storage, it needs to be connected to the peer to peer network of that parachain. And to submit transactions it needs to download the runtime of that parachain.

Smoldot is capable of connecting to many different chains at the same time. The only limit at the moment is the available wasm memory space of 4 GiB, which at the moment makes it possible to be connected to 20/30 different chains at the same time. I haven't fully explored all the memory optimization possibilities available, so this could be further improved. When 64bits wasm becomes supported by browsers, there will basically be no limit anymore.

Are the current bootnodes not WS enabled? If not, why do the bootnodes need to be WS enabled in the first place? Couldn't the light client find another node in the network to use (after entering the network via "regular" bootnode)?

Browsers in general only allow WebSocket connections. If you run a light client inside of a browser you need to suffer from this limitation. Nodes that aren't "WS enabled" simply cannot receive any incoming connection from browser light clients.

We're working on supporting WebRTC, which will make a lot of things way easier. For this reason we're currently balanced between two chairs at the moment: in order to connect to a chain, their bootnodes need to be reachable through WebSocket, but we know that in the future this configuration will need to change again.

[bernardoaraujor]

@NachoPal I reverted the commit that introduced ksmcc3, as the discussion will be followed on #1205

The PR should be quite straightforward now, simply adding wss bootnodes.

[bernardoaraujor]

it seems we need one extra approval @bkchr