In order for browsers-embedded applications to be able to directly connect to the peer-to-peer network of a chain, there exists three protocols: WebSocket, WebTransport, or WebRTC.
Unfortunately, the first two require the server you connect to to expose a (non-self-signed) TLS certificate. This is ideologically problematic, as we don't want users of our software to have to deal with registering certificates. Browser-embedded applications should have a wide range of accessible peers, and the higher the barrier to making a client accessible, the fewer peers will be accessible.
WebSocket and WebTransport also come with a known security issue w.r.t. to our use case which I would prefer to not disclose publicly in an issue.
For these reasons, we want to use WebRTC. WebRTC has the advantage of existing specifically for peer-to-peer networking, meaning that even if changes are ever made to the WebRTC protocol (such as extra security requirements), we should be able to accommodate them.
As a side note, we're currently sponsoring the webrtc-rs library, which is not owned by us but will be used by the Substrate implementation: https://opencollective.com/webrtc-rs
Open Questions
The quality of the webrtc-rs library is unfortunately not the best. Is it wise to enable it by default on all Substrate nodes? A bug in the library could make it possible for an attacker to crash nodes.
The Vision
In order for browsers-embedded applications to be able to directly connect to the peer-to-peer network of a chain, there exists three protocols: WebSocket, WebTransport, or WebRTC.
Unfortunately, the first two require the server you connect to to expose a (non-self-signed) TLS certificate. This is ideologically problematic, as we don't want users of our software to have to deal with registering certificates. Browser-embedded applications should have a wide range of accessible peers, and the higher the barrier to making a client accessible, the fewer peers will be accessible.
WebSocket and WebTransport also come with a known security issue w.r.t. to our use case which I would prefer to not disclose publicly in an issue.
For these reasons, we want to use WebRTC. WebRTC has the advantage of existing specifically for peer-to-peer networking, meaning that even if changes are ever made to the WebRTC protocol (such as extra security requirements), we should be able to accommodate them.
The Plan
As a side note, we're currently sponsoring the
webrtc-rslibrary, which is not owned by us but will be used by the Substrate implementation: https://opencollective.com/webrtc-rsOpen Questions
The quality of the
webrtc-rslibrary is unfortunately not the best. Is it wise to enable it by default on all Substrate nodes? A bug in the library could make it possible for an attacker to crash nodes.