You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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-rs
library, 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-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 text was updated successfully, but these errors were encountered: