libp2p-webrtc-browser-to-server blog post

[ddimaria]

Creates a blog post detailing the WebRTC transport in libp2p.

todo:

• Blog header https://www.notion.so/crcle/libp2p-WebRTC-blog-header-5664042c6d4c4d7ca71863588235b4a6
• Updated design and diagrams https://www.notion.so/crcle/WebRTC-Blog-Post-Diagrams-465610a5d0b644889e6ca3edebe89bcd

[marten-seemann]

Some high-level comments:

1. 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”.
2. 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.
3. 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.
4. 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?
5. 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?
6. 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.

[p-shahi]

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?)

[salmad3]

Nice blog @ddimaria! Added comments.

[mxinden]

Thanks for the many improvements @ddimaria!

And thanks to the many reviewers here.

[ddimaria]

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?)

@p-shahi that diagram has been removed.

[ddimaria]

@p-shahi @mxinden @marten-seemann @DannyS03 Would you like any additional changes in this PR?

[thomaseizinger]

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 levels¹ should also be smaller.

Footnotes

1. 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 🙃 ↩

[thomaseizinger]

@ddimaria This is still missing.

[BigLep]

Thanks for writing - good stuff!

A few things:

1. 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/
2. It wasn't clear to me from reading whether WebRTC suffers from double encryption. Lets make a clear statement here.
3. 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.
4. 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!

[BigLep]

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.

[ddimaria]

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.

[thomaseizinger]

1. 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/

This should be fixed by merging latest master into this branch. See #40.

[jxs]

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.

[mxinden]

Two more comments on the diagram. Sorry for missing this earlier.

[mxinden]

I left comments on each conversation. Most of them should be actionable now. Can you do the follow-ups @ddimaria?

[mxinden]

Great to see this merged. Thanks for all the work everyone.

Small typo here (DTLS vs DLTS), not sure whether fixing it is worth the effort.

[p-shahi]

@mxinden Thanks for the catch: fixed via #48

[mxinden]

That was fast. Thanks @p-shahi!