Skip to content
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

Enable WebRTC Transport #9724

Closed
2 tasks
BigLep opened this issue Mar 15, 2023 · 7 comments · Fixed by #10463
Closed
2 tasks

Enable WebRTC Transport #9724

BigLep opened this issue Mar 15, 2023 · 7 comments · Fixed by #10463
Labels
dif/hard effort/weeks Estimated to take multiple weeks P1 High: Likely tackled by core team if no one steps up

Comments

@BigLep
Copy link
Contributor

BigLep commented Mar 15, 2023

Done criteria

  1. libp2p's WebRTC transport is enabled by default.
  2. There are corresponding docs that describe how/why to use this.

Background

WebRTC provides another way for browsers to connect with the rest of the libp2p network (beyond WebTransport which is Chromium only at least as of 2023-03-14). We want to enable browser nodes to be able to communicate easily with other nodes in the network. To accomplish this we need a good amount of nodes in the network to have webtransport/webrtc listen addresses. Getting Kubo nodes having WebTransport listening by default is a good way to increase the number of nodes that browser nodes can connect to.

Preconditions

  1. go-libp2p WebRTC transport (WebRTC Direct transport implementation libp2p/go-libp2p#2337 ) is merged and released.

Notes about the work involved

  1. Documenting the browser/Kubo communication story is covered Document how to connect browser nodes with Kubo nodes using WebTransport ipfs-docs#1286
  2. Similar issues from when we did this for WebTransport:
  1. With WebTransport we first had this as experimental. This may change, but my current proposal is that we enable it by default from the start
@BigLep BigLep moved this to 🥞 Todo in IPFS Shipyard Team Mar 15, 2023
@BigLep
Copy link
Contributor Author

BigLep commented Mar 15, 2023

I expect this will land in Kubo 0.21 (not 0.20) given Kubo maintainers are busy preparing for IPFS Thing and WebRTC hasn't shipped in go-libp2p yet.

@BigLep BigLep moved this from 🥞 Todo to 🛑 Blocked in IPFS Shipyard Team Apr 19, 2023
@SgtPooki
Copy link
Member

SgtPooki commented Jul 6, 2023

@lidel It seems like this didn't land in 0.21, and was moved to blocked. Can we get a list of the next action items and ETA?

@BigLep
Copy link
Contributor Author

BigLep commented Jul 6, 2023

@SgtPooki : unfortunately we don't have WebRTC in go-libp2p yet. Here is the new PR: libp2p/go-libp2p#2337 . I have updated the "Preconditions" above. I believe go-libp2p is targeting mid-July, so I would expect this makes it into Kubo for 0.23 (end of August/early September)

@marten-seemann
Copy link
Member

We're planing to ship experimental WebRTC support in go-libp2p v0.31. "Experimental" here means that to the best of our knowledge, the spec is implemented correctly, which means that it's possible to establish WebRTC connections and transfer. However, we make no guarantees regarding performance and resilience against resource exhaustion attacks.

Therefore, WebRTC should not be enabled by default at this point. Instead we should follow the rollout plan we used for the QUIC transport a couple of years ago, meaning that there should be a config flag to enable the WebRTC transport.
In order to enable the WebRTC transport on the server side, nodes will also need to configure a WebRTC swarm listen address.

@BigLep
Copy link
Contributor Author

BigLep commented Nov 9, 2023

Kubo 0.25 conversation: there will be work here if there is a new go-libp2p that has webrtc-direct that is non-experimental and/or if there is the webrtc (private-to-private) support

@BigLep
Copy link
Contributor Author

BigLep commented Nov 30, 2023

2023-11-30 conversation: given the conditions in #9724 (comment) haven't happened, there is no work for 0.25 on this. This is blocked until libp2p/go-libp2p#2656 is addressed.

@lidel lidel added effort/days Estimated to take multiple days, but less than a week dif/hard effort/weeks Estimated to take multiple weeks P1 High: Likely tackled by core team if no one steps up and removed effort/days Estimated to take multiple days, but less than a week labels Dec 4, 2023
@lidel
Copy link
Member

lidel commented Apr 23, 2024

wip /webrtc-direct with /certhash: libp2p/go-libp2p#2774

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dif/hard effort/weeks Estimated to take multiple weeks P1 High: Likely tackled by core team if no one steps up
Projects
No open projects
Status: 🥞 Todo
Development

Successfully merging a pull request may close this issue.

5 participants