WebRTC connectivity guide

[2color]

This PR adds a new guide on WebRTC with js-libp2p for browser-to-browser connectivity.

TODO

Tasks

Beta Give feedback

1. rename file to webrtc js-libp2p

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
libp2p-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 11, 2024 5:42pm

[2color]

I just made Vercel previews public, so anyone opening this PR should be able to preview

[achingbrain]

This is great. Some thoughts:

• Nothing here is browser specific, all of this applies to using the WebRTC transport to dial browsers from Node.js so it might be worth mentioning that?
  • Dialling browsers from non-browsers is only possible in js-libp2p right now, that's not really touched on here
• A lot of time is spent discussing how to automatically discover the listener peer's address, including using GossibSub to do so
  • It's rare to want to dial a specific peer for no reason, normally you want to dial a peer because they have something you want like an IPFS block, in which case you would have found their address during a search for providers
  • GossipSub is a big dep that causes the node to do a lot of work, it's inclusion comes with a lot of overhead
• Language/diagrams could be simplified by using roles (e.g. Dialer/Listener) instead of Peer 1/Peer 2
• The role of the relay/bootstrapper becomes a bit overloaded since it's used for connection establishment but also peer discovery
  • Maybe it could be two separate nodes to make it clear that the peer discovery part isn't a hard dependency of establishing the connection, it's just a way for the dialler to not have to copy/paste the multiaddr of the listener?
  • Alternatively peer discovery could be moved out of scope here and covered elsewhere?
  • The name "bootstrapper" is a bit confusing since what we normally refer to as "bootstrappers" are nodes run to enable populating routing tables
• The context switch between js and go for the relay is a bit jarring, also considering people reading this will like be JS people, but it is covered at the end of the article.
  • It's a little odd that we recommend using go-libp2p for the relay because it has WebTransport, but WebTransport is still pretty broken in browsers. WebSockets, although tedious to configure, do work very well and are available everywhere. Not sure there's a good answer here.

[2color]

• Nothing here is browser specific, all of this applies to using the WebRTC transport to dial browsers from Node.js so it might be worth mentioning that?

  • Dialling browsers from non-browsers is only possible in js-libp2p right now, that's not really touched on here

This is pretty cool. I never thought about it this way, but will definitely weave this into the guide.

• The name "bootstrapper" is a bit confusing since what we normally refer to as "bootstrappers" are nodes run to enable populating routing tables

Do you think Relay is a better term? Which term would you recommend here?

The context switch between js and go for the relay is a bit jarring, also considering people reading this will like be JS people, but it is covered at the end of the article.

• It's a little odd that we recommend using go-libp2p for the relay because it has WebTransport, but WebTransport is still pretty broken in browsers. WebSockets, although tedious to configure, do work very well and are available everywhere. Not sure there's a good answer here.

Fair point. I'll give writing the relay in node.js with WebSockets. Since the guide is only running in localhost, we don't need a certificate, so this may work well.

[2color]

@achingbrain Mind giving this another review. I've addressed all your feedback and think this is ready to be merged.

[dhuseby]

This is great!! I just cleaned up some passive voice for clarity.

[dhuseby]

LGTM. Send it.