Roadmap for allowing browser-embedded nodes to connect to Substrate networks

[tomaka]

• Make it possible for node operators to attach a TLS certificate to their libp2p WebSocket server. I believe this can be done by adding a CLI option that passes a certificate.

• Add a WebRTC "client" in nodes.

• Implement some mechanism for nodes to relay WebRTC SDPs, in other words to act as signalling servers. This point is quite vague and needs more thoughts.

[tomaka]

cc libp2p/rust-libp2p#1066

[tomaka]

Make it possible for node operators to attach a TLS certificate to their libp2p WebSocket server. I believe this can be done by adding a CLI option that passes a certificate.

I put that item here because it believe that it isn't super hard to implement.
However, it might be easier to just ask people to put a reverse proxy with a certificate in front of the WebSocket endpoint.

[MichaelMackus]

Make it possible for node operators to attach a TLS certificate to their libp2p WebSocket server. I believe this can be done by adding a CLI option that passes a certificate.

I put that item here because it believe that it isn't super hard to implement.
However, it might be easier to just ask people to put a reverse proxy with a certificate in front of the WebSocket endpoint.

You could also do what js-libp2p does in their docs for the webrtc-star server, and provide a docker-compose file to automatically setup the reverse proxy. The nice thing is this way letsencrypt setup can be automated as well.

[expenses]

However, it might be easier to just ask people to put a reverse proxy with a certificate in front of the WebSocket endpoint.

We're already doing this for parity nodes, so this is probably the way to go instead of modifying the client.

[tomaka]

Since this issue has been opened, we realized that in the context of a browser extension, non-secure WebSockets worked.

Therefore, another thing that can be considered is that nodes that nodes all listen through the WebSocket protocol by default, unless for example they were started using --validator.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[tomaka]

Issue still relevant and important.

[tomaka]

cc libp2p/specs#220

[tomaka]

ipfs/js-ipfs#611 seems like a big problem.

[tomaka]

Progress is done here:
libp2p/rust-libp2p#2622
libp2p/specs#412

[tomaka]

Would be closed by paritytech/substrate#12529

[tomaka]

I don't know what the involved and some_time_soon labels really mean, but this really should be done "some time soon". It's a very high priority change for light clients, and just because it's a difficult change shouldn't mean that it should be left on the side to rot.

As a reminder, light clients have an undisclosed vulnerability that can only be fixed by WebRTC.

I know that this has been waiting for years at this point, but just because it's been waiting for a long time doesn't mean that it should continue taking a long time.

[altonen]

I think the label regarding urgency has been removed but it's still a high-priority task for us