Closed lidel closed 3 years ago
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.
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)
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..
?
Refs: