WebRTC-Direct transport at risk due to Chrome changes (ICE credential munging): alignment and next steps

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:

1. browser to public libp2p server dialing
2. without signalling
3. 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:

1. onboarding flows
2. public node access patterns
3. 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.