-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make this clearer
|
||
#### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the write-up @p-shahi. A couple of comments and suggestions.
Co-authored-by: Marten Seemann <martenseemann@gmail.com> Co-authored-by: Max Inden <mail@max-inden.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple smaller nits. Overall this looks good to me. Thanks for the follow-ups.
- _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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ICE candidates are part of the SDP, thus is a duplicate of the bullet above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the work here.
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