Learn more about how libp2p achieves universal connectivity across networks.
Public nodes is any node running in a data centers, or on a dedicated connection without any router / NAT / firewall in between.
Full nodes (e.g. go-libp2p, rust-libp2p, node.js-libp2p) use TCP and QUIC to connect to each other.
TCP is a...
QUIC is a UDP-based transport protocol which is always encrypted (using TLS 1.3) and provides native stream multiplexing.
Whenever possible, QUIC should be preferred over TCP. For more benefits of using QUIC, see #holepunching.
However: UDP is blocked in ~5-10% of networks. Therefore TCP is still needed as a fallback.
Not all nodes are located in a publicly reachable position. Most nodes are behind NATs or firewalls: in home networks, in corporate networks, and even on mobile devices (carrier-grade NATs).
Nodes behind firewalls / NATs can dial any node on the public internet, but they cannot receive incoming connections from outside their local network.
We want to be able to access the libp2p network from a web browser. Browsers are really, really good at speaking HTTP (using an underlying TCP connection for HTTP/1.1 and HTTP/2, and a QUIC connection for HTTP/3), but they don't allow access to the underlying connection.
HTTP is a request-response scheme. The client (browser) sends a request, and then waits for a response.
libp2p on the other hand deals with streams. A stream is more flexible than a request-response scheme: it allows continuous bidirectional communication, both parties can send and receive data at any time.
WebSocket has been around for more than 10 years. It allows “hijacking” of a HTTP/1.1 connection (it was later also standardized for HTTP/2), giving the browser access to the underlying TCP connection.
go-libp2p: ✔
rust-libp2p: ✔
node.js-libp2p: ???
Chrome: ✔
Firefox: ✔
Safari: ✔
There are solutions to assign certificates to a fleet of nodes, see for example https://words.filippo.io/how-plex-is-doing-https-for-all-its-users/.
Another option would be using IP certificates. They’re quite rare, and not a lot of CAs support generating them, but this might be worth investigating.
While WebSockets allows the browser to “hijack” a TCP connection, WebTransport does the same thing with a QUIC connection.
The protocol is brand-new, in fact, there’s not even an RFC yet: It’s still under development by the IETF WebTransport Working Group and the W3C WebTransport Working Group.
go-libp2p: ⏱ (work in progress)
rust-libp2p: ❌
node.js-libp2p: ❌
Chrome: ✔️
Firefox: ⏱ (work in progress, TODO: link to issue)
Safari: ❌ (status unknown)
This is a very new protocol, and we can use your help.
Specification: https://github.com/libp2p/specs/pull/404
Go implementation: https://github.com/marten-seemann/webtransport-go
Some content here?
Usually used for video conferencing, WebRTC is a suite of protocols that allows browsers to connect to servers, and to other browsers, and even punch through NATs.
In addition to enabling audio and video communication (for which packets are sent using an unreliably transport), WebRTC also establishes stream-based communication on top of SCTP and exposes reliable streams, called WebRTC Data Channels.
go-libp2p: working on the implementation
rust-libp2p: working on the implementation
js-libp2p: working on the implementation
Made with love by Protocol Labs