-
Notifications
You must be signed in to change notification settings - Fork 7
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
libp2p-webrtc-browser-to-server blog post #18
libp2p-webrtc-browser-to-server blog post #18
Conversation
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.
Some high-level comments:
- General theme: The WebRTC handshake does a lot of things. We actually don’t need 90% of these things in libp2p, we only do them so we can use WebRTC (because it’s implemented in browsers). My wish is that this would be the theme of this blog post: “WebRTC forces us to do X, we get around this by doing Y”.
- Comparison with other transports: I think we should keep that section shorter. For example, for WebSocket it should suffice to say that getting the CA-signed certs is a problem, and link to the WebTransport article.
- WebTransport: I feel like the comparison is incomplete.
- While Chrome is currently the only browser implementation of the protocol, there’s commitment from both Mozilla and Apple to implement the protocol, judging from their involvement in the standardization process in the IETF WebTransport working group.
- It’s not unreasonable to assume that by some point in 2023, we’ll see implementations of the protocol in Firefox and Safari as well (depending on how fast the work at the IETF progresses).
- Really, there’s no reason whatsoever to prefer dialing a WebRTC over dialing a WebTransport connection. I assume that nodes will aggressively prefer WebTransport over WebRTC when connecting to a node that supports both transports.
- I realize that this makes the WebRTC browser to server work look less rosy, but we should help people gain an accurate understanding of the situation we’re in: it fills the gap until the RFC is out, and other browsers have caught up with Chrome and until rust-libp2p has caught up with go-libp2p with their respective WebTransport implementations.
- WebRTC resource requirements: Chinmay mentioned that at least the Pion implementation is quite resource hungry (not sure about the Rust implementation). Would it make sense to provide some numbers on that, or at least mention that in the limitations?
- WebRTC stream framing: We had to bend over backwards to get stream resets working, introducing our own Protobuf-based stream data framing. Can we mention that (and why) we did that?
- Diagrams:
- Am I right to assume that the plan is to put in a design request with Crcle, once we’ve agreed on what exactly should be in the diagrams?
- We’ve started putting the client on the left side, we should keep it consistent.
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.
A first pass review, added some thoughts will come back to this again.
I'll also submit a request to the Crcle design team to get started on the blog header and diagrams. The timeline will probably be sometime in January.
A diagram for WebRTC in libp2p is a must have but I'm on the fence about the general WebRTC one (whether we should include it at all...it is a good contrast to have but is it really necessary?)
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.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.
Nice blog @ddimaria! Added comments.
Co-authored-by: Danny Salman <salman.danny03@hotmail.com>
Co-authored-by: Danny Salman <salman.danny03@hotmail.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 many improvements @ddimaria!
And thanks to the many reviewers here.
Co-authored-by: Danny Salman <salman.danny03@hotmail.com> Co-authored-by: Max Inden <mail@max-inden.de>
…/blog into libp2p-webrtc-browser-to-server
Co-authored-by: Danny Salman <salman.danny03@hotmail.com>
@p-shahi that diagram has been removed. |
@p-shahi @mxinden @marten-seemann @DannyS03 Would you like any additional changes in this PR? |
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.
A few more minor comments. I kicked CI so we have a preview here now: https://bafybeif4ufb36f7df54maoqxp3s6xuskjju7oqv7d62kfqua7bp5kyhmx4.on.fleek.co/libp2p-webrtc-browser-to-server/
It is not something we can fix in this PR but overall, I find the layout of the blog hard to read. Especially the different levels of headings (##
vs ###
vs ####
) are visually too similar in my opinion. Look at https://bafybeif4ufb36f7df54maoqxp3s6xuskjju7oqv7d62kfqua7bp5kyhmx4.on.fleek.co/libp2p-webrtc-browser-to-server/#benefits for example. The spacing between the headings and paragraphs, as well as the font-sizes of the headings make each paragraph look the same when really, each paragraph should be visually closer to its heading and the spacing between two headings of different levels1 should also be smaller.
Footnotes
-
Really, that case shouldn't exist because headings should always have a content other than further headings but that is getting a bit too academic now 🙃 ↩
- webrtc | ||
title: WebRTC in libp2p | ||
description: | ||
date: |
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.
@ddimaria This is still missing.
Suggestion from @thomaseizinger Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
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 writing - good stuff!
A few things:
- We're still getting the weird rendering behavior of all newlines translating to a newline in the rendered view. I saw this looking at https://bafybeicsnvslzcjo6u6l4rbmrlmpunmnezuu53ksmt7v766tlavz3hqd3m.on.fleek.co/libp2p-webrtc-browser-to-server/
- It wasn't clear to me from reading whether WebRTC suffers from double encryption. Lets make a clear statement here.
- I left some comments on this, but please give thought on how to be clear that we're talking about "public server" in this post.
- I likely won't be able to engage more on this post the week of 2023-01-23. I'm hoping @p-shahi can champion answering any open questions and ensuring the feedback was incorporated/resolved.
Thanks again!
``` | ||
|
||
The only difference from other transports is initializing with `webRTC()`. That's all you need to do to implement WebRTC in the browser. Easy, right? | ||
## Alternative transports |
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 consider removing this seciton. I think it makes more sense in the connectivity website or the docs. Basically keep the post focused on WebRTC and leave education about other transports to other places.
Maybe we have a post at the end of the connectivity series that gives a textual overview of the pros and cons of the transports.
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 can see the benefits of keeping it as well as removing it. It really depends if a blog post reader use case includes reading the post in isolation (not reading other blog posts and/or not relying on external links). The additional information doesn't overwhelm the reader in this case, but offers an immediate compare/contrast experience. I'll let others weigh in on this.
Co-authored-by: Steve Loeppky <stvn@loeppky.com>
This should be fixed by merging latest master into this branch. See #40. |
|
||
In most cases, peers directly connect to other peers, improving privacy and requiring fewer hops than on a relay. Peers connect via an [RTCPeerConnection](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection) interface. Once connected, [RTCDataChannels](https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel) can be added to the connection to send and receive binary data. | ||
|
||
To connect to each other, peers need to learn their public IP address and any router restrictions along the path that would prohibit peer-to-peer communication. WebRTC specifies the [STUN](https://datatracker.ietf.org/doc/html/rfc3489) protocol for that. In the case of a restriction, [TURN](https://datatracker.ietf.org/doc/html/rfc8656) servers relay data between peers using a Signaling Channel. In libp2p, we don't use these protocols. |
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.
Agreed. Also technically it's not correct, a browser uses a STUN binding request to get its public ip (server reflexive candidate) from the server node using ICE Lite.
Wdyt of expanding on the wording used on the spec?
Given that B is publicly reachable, B acts as a ICE Lite agent. It binds to a UDP port waiting for incoming STUN and SCTP packets and multiplexes based on source IP and source port.
Co-authored-by: Danny Salman <salman.danny03@hotmail.com> Co-authored-by: João Oliveira <hello@jxs.pt>
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.
Two more comments on the diagram. Sorry for missing this earlier.
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 left comments on each conversation. Most of them should be actionable now. Can you do the follow-ups @ddimaria?
Co-authored-by: Max Inden <mail@max-inden.de>
That was fast. Thanks @p-shahi! |
Creates a blog post detailing the WebRTC transport in libp2p.
todo: