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

Make WebRTC non experimental #2657

Open
Tracked by #2778
sukunrt opened this issue Nov 27, 2023 · 1 comment
Open
Tracked by #2778

Make WebRTC non experimental #2657

sukunrt opened this issue Nov 27, 2023 · 1 comment
Labels
effort/weeks Estimated to take multiple weeks exp/wizard Extensive knowledge (implications, ramifications) required kind/tracking A meta-issue for tracking work status/blocked Unable to be worked further until needs are met

Comments

@sukunrt
Copy link
Member

sukunrt commented Nov 27, 2023

Currently WebRTC has been deployed with an experimental tag and has the following caveat: https://github.com/libp2p/go-libp2p/blob/master/p2p/transport/webrtc/transport.go#L4-L7

// While we're fairly confident that the implementation correctly implements the specification,
// we're not making any guarantees regarding its security (especially regarding resource exhaustion attacks).
// Fixes, even for security-related issues, will be conducted in the open.

We should remove aim to experimental tag and make this transport enabled by default.

@marten-seemann
Copy link
Contributor

To make WebRTC a default transport:

  1. We need to be sure that the resource usage is acceptable (see webrtc: investigate resource usage #1917), both in our code and in the underlying Pion WebRTC and SCTP stack.
  2. webrtc: wait for FIN_ACK before closing data channels #2615 needs to be resolved and merged.
  3. Deployment experience that shows actual usage of the WebRTC transport would be nice. Even better if it comes with metrics.

We should consider bundling this with WebRTC private-to-private. It seems like the above points would most likely be satisfied for both WebRTC flavors at the same time.

@marten-seemann marten-seemann added status/blocked Unable to be worked further until needs are met effort/weeks Estimated to take multiple weeks exp/wizard Extensive knowledge (implications, ramifications) required kind/tracking A meta-issue for tracking work labels Dec 7, 2023
@sukunrt sukunrt mentioned this issue Apr 25, 2024
19 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/weeks Estimated to take multiple weeks exp/wizard Extensive knowledge (implications, ramifications) required kind/tracking A meta-issue for tracking work status/blocked Unable to be worked further until needs are met
Projects
None yet
Development

No branches or pull requests

2 participants