Does js-libp2p WebRTC fallback to a relayed connection when direct connection failed?

[jmatsushita]

The spec says:

Behavior for transferring data on a relayed connection, in the case where the direct connection failed, is out of scope for this specification and dependent on the application.

Could confirm whether the fall back is implemented in js-libp2p and in the webrtc/browser-to-browser example?

[achingbrain]

At the moment there's no fallback as such.

When dialling a WebRTC address if there's a relayed connection already open to the remote peer it'll remain open afterwards.

If there's no relayed connection, a temporary one will be opened but it will be closed on WebRTC success or failure.

An application could dial the circuit relay address explicitly if the WebRTC address fails, but the next problem it would encounter is that any long-lived or data-heavy protocols (gossipsub, bitswap, kad-dht, etc) will not run over relayed connections, only direct ones so the relayed connection isn't of much use.

This is because relayed connections are data/duration limited and these protocols will trip the limits causing the connection to be killed by the relay unexpectedly.

What use do you see for a fallback to the underlying relayed connection when dialling WebRTC?

[jmatsushita]

Thanks a ton. That clears a lot of things up "circuit relays" are not "data relays". I had the TURN approach in mind, hence the confusion. The main use case I'm imagining is the same as for TURN specifically when direct connection isn't possible. I'm also wondering whether something like SFUs or Cascading SFUs could be implemented with hypothetical "data relays" but I suppose that would entail some delegation and trust mechanisms, maybe with something like UCAN? Is that a wheel that's been invented already in the libp2p ecosystem, or is that out of scope because it's not really p2p anymore?

[jmatsushita]

I see that some of this was discussed before by @jacobheun

• The nodes establish a direct connection to one another over the WebRTC (or other) transport
  • What happens if this fails? Should the nodes continue to leverage the Relay to exchange data? If so, it may be expensive for the relay node. If not, how can the nodes talk to one another?
    • If there was a distinction between nodes behaving as only "signaling relays", and nodes behaving as "data exchange relays", nodes could potentially be customized to support high/low connections or high/low bandwidth.