Experiment with enabling WebRTC in js-ipfs fallback

[lidel]

What if we enable WebRTC in fallback js-ipfs node?

In the past browsers had stability issues when js-ipfs run with webrtc transport for a long time.
We had various changes since then across the stack and the tab with share app will usually be closed after user is done with upload/download minimizing risk of it running for long enough to cause trouble.

Could WebRTC potentially..

• improve discovery and performance of sharing app
• give more merit to p2p claims made in copy/docs :)
• build better understanding of how stable WebRTC transport is today, identify pain points and work towards addressing them in ipfs/libp2p/browser stack.

?

Refs:

• Stable transports in the browser - Stable transports in the browser ipfs/js-ipfs#1088
  • Notes on IPFS+WebRTC tuning done by Paratii team - Stable transports in the browser ipfs/js-ipfs#1088 (comment)
  • WebRTC ignoring(?) connection manager's limits - Stable transports in the browser ipfs/js-ipfs#1088 (comment)

[olizilla]

I'm for this, but not yet. I think we need to make "understanding WebRTC limits and tuning" a high priority. I'd rather have us dedicate focused time to understandting the root causes of the problem and the effects of the tuning options before enabling it again on an app.

[lidel]

iiuc we switched to the latest js-ipfs where webrtc is enabled by default supported

Update: turns out explicit signaling addr needs to be passed + we need to tweak transport manager's fault tolerance to be NO_FATAL, so js-ipfs still works even if all signaling servers are down (we still have wss to bootstrappers/preloads)