feat: add private-to-private docs #319
Conversation
|
@mxinden let me know what you think. Reading the specs was quite helpful but I may have gotten a few things wrong. While this is ready for review, I think we should block this until both the implementation and specs PR are merged (I would like to link out to both from this doc.) |
| Applications are sandboxed and face constraints on security and networking. | ||
| For instance, browsers do not permit direct access to raw network sockets. | ||
| Additionally, it's a sure bet that libp2p browser nodes will be behind a NAT/firewall. | ||
| Due to these restrictions, browser nodes cannot listen for incoming connections, |
There was a problem hiding this comment.
They also can't dial TCP and QUIC connections.
| The technical specification and initial implementations of WebRTC | ||
| Browser-to-Browser connectivity is planned for release in early 2023. | ||
| Track the progress [here](https://github.com/libp2p/specs/issues/475). | ||
| Thankfully, libp2p solves this problem and enables browser node to browser node connectivity by supporting a transport called WebRTC W3C. |
There was a problem hiding this comment.
Why W3C? All the W3C is does is specify the browser API. We don't call WebTransport "WebTransport W3C".
| Thankfully, libp2p solves this problem and enables browser node to browser node connectivity by supporting a transport called WebRTC W3C. | |
| Thankfully, libp2p solves this problem and enables browser node to browser node connectivity by supporting WebRTC. |
There was a problem hiding this comment.
Leaving this until the convo in specs is resolved.
| Thankfully, libp2p solves this problem and enables browser node to browser node connectivity by supporting a transport called WebRTC W3C. | ||
|
|
||
| {{< alert icon="" context="info">}} | ||
| Due to the restrictions mentioned above, libp2p browser nodes are private nodes (meaning they cannot be dialed from outside of their local network). |
There was a problem hiding this comment.
Not really. They're private nodes because people run their browsers in their home / corporate networks, and those networks almost always use NATs. In principle, you could run your browser on a machine that has a public address.
|
|
||
| #### Transport Internals | ||
|
|
||
| The libp2p WebRTC W3C transport is enabled by supporting the [W3C defined](https://w3c.github.io/webrtc-pc/#introduction) `RTCPeerConnection` API. |
There was a problem hiding this comment.
I don't think mentioning W3C makes a lot of sense here. I will engage on the specs PR. Browser-to-server also uses the W3C-defined API, simply because that's the API that's available in browsers.
|
|
||
| The libp2p WebRTC W3C transport is enabled by supporting the [W3C defined](https://w3c.github.io/webrtc-pc/#introduction) `RTCPeerConnection` API. | ||
| This core API enables p2p connectivity and provides methods for establishing connections and transferring streams of data between peers. | ||
| Running instances of libp2p that support this transport will have `/webrtc-w3c` in their multiaddr. |
There was a problem hiding this comment.
Same here, I don't think we should go with this multiaddr, but I'll comment on the PR in the multiaddr repo.
There was a problem hiding this comment.
Commented: multiformats/multiaddr#150 (comment).
| This core API enables p2p connectivity and provides methods for establishing connections and transferring streams of data between peers. | ||
| Running instances of libp2p that support this transport will have `/webrtc-w3c` in their multiaddr. | ||
|
|
||
| However, there's more to p2p connections that what `RTCPeerConnection` provides. Crucially, signaling isn't built into the WebRTC API. |
There was a problem hiding this comment.
It kind of is. The W3C gives you the signaling messages, you just need to figure out how to ship them to the peer yourself.
There was a problem hiding this comment.
I see, might have misrepresented what was described here: "Signaling methods and protocols are not specified by WebRTC. Signaling is not part of the RTCPeerConnection API."
I'll take a note out of this: https://webrtc.org/getting-started/peer-connections#signaling and reword as:
"Crucially, the WebRTC specification doesn't prescribe any single solution for signaling. The peer connection API has a notion of signaling state but not mechanism to share this data with remote peers."
lmk what you think
p-shahi
changed the title
Co-authored-by: Marten Seemann <martenseemann@gmail.com> Co-authored-by: Max Inden <mail@max-inden.de>
| - _A_ initiates the `webrtc-signaling` protocol to _B_ via a stream over the relayed connection | ||
| - This signaling stream is used to: | ||
| - Exchange SDPs between nodes (an offer from _A_ and an answer from _B_) | ||
| - Exchange information about the network connection (in WebRTC parlance this is called [exchanging ICE candidates](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity#ice_candidates)) |
There was a problem hiding this comment.
The ICE candidates are part of the SDP, thus is a duplicate of the bullet above.
There was a problem hiding this comment.
I would like to keep this, made it a subpoint of the previous line.
Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
|
Thanks @mxinden will wait for either libp2p/js-libp2p-webrtc#90 or libp2p/specs#497 to land before merging |
|
libp2p/js-libp2p-webrtc#90 is in, merging! |
closes #302