WebRTC-Direct transport at risk due to Chrome changes (ICE credential munging): alignment and next steps
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 6.9k
- Forks
- 1.3k
- Avg merge
- 13d 21h
- Merged PRs (30d)
- 1
Description
Description
Sharing a consolidated update from recent discussions across js-libp2p, py-libp2p and specs to align on implications for go-libp2p.
This needs attention as it impacts core connectivity guarantees for browser and server communication.
Context
Recent threads to review:
- Summary by lidel on WebRTC-Direct + Chrome changes (specs#672 comment at https://github.com/libp2p/specs/issues/672#issuecomment-4297060067 )
- feat: webrtc-direct-v2 : https://github.com/libp2p/js-libp2p/pull/3480
- docs: webrtc-direct-v2 : https://github.com/libp2p/specs/pull/715
- Summary by lidel on WebRTC-Direct + Chrome changes (specs#672 comment at https://github.com/libp2p/specs/issues/672#issuecomment-4297060067 )
- Py-libp2p discussion: https://github.com/libp2p/py-libp2p/pull/1309#issuecomment-4337569723
Summary of the Problem
The /webrtc-direct transport is at risk due to upcoming changes in Google Chrome.
- WebRTC-Direct exists primarily to allow:
- browser to public libp2p server dialing
- without signalling
- without CA-signed certificates
- This relies on ICE credential munging (SDP manipulation)
- Chrome is introducing a restriction (WebRTC-NoSdpMangleUfrag) that breaks this mechanism
When this change rolls out:
- Browser to server connectivity via /webrtc-direct may stop working
- The core reason for this transport’s existence is undermined
Impact
- Existing assumptions about browser and server direct connectivity may no longer hold
- /webrtc-direct could degrade or become unusable
- Affects:
- onboarding flows
- public node access patterns
- browser-based libp2p applications
Priority
High
This is externally driven (Chrome changes) and affects a foundational transport. Delay risks breaking connectivity for browser-based libp2p usage.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the linked specs#672 discussion, js-libp2p PR #3480, specs PR #715, and py-libp2p PR #1309 to understand the Chrome restriction and its impact on go-libp2p. Identify the affected WebRTC-Direct entry points and tests in this repository, then define agreed next steps and a testable connectivity outcome with maintainers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- audio-video-rtc, networking
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100