Enable WebRTC by default in the browser?

[achingbrain]

We could enable a /dns4/wrtc-star.discovery.libp2p.io/tcp/443/wss/p2p-webrtc-star address by default for the browser config.

We could also enable transport manager fault tolerance for the browser libp2p config so it doesn't crash the node if /dns4/wrtc-star.discovery.libp2p.io is unavailable.

Pro: When it works, it works:tm:
Con: When it doesn't, the user will not know why it doesn't work

cc @vasco-santos @lidel

[lidel]

reposting from private channels (cc @autonome @Gozala)

IIf we enable this, most of js-ipfs nodes will use the default (implicit) signaling server, and it may not perform well under high load.

This is a problem IMO, because if that service goes down, js-ipfs will fail to start.

We could mitigate that by configuring transport manager to not fail js-ipfs start process if signaling server is down:

  transportManager: {
    faultTolerance: FaultTolerance.NO_FATAL
  }

---

I'm 👍 for doing this in browser bundle + displaying prominent console log warning when default webrtc-star is used with link to self-hosting instructions at: https://github.com/libp2p/js-libp2p-webrtc-star/blob/master/DEPLOYMENT.md

(self-hosting should be the only way to turn embarrassing console error/warning off)

[autonome]

+1 to:

• "Just Works™️" most of the time
• with some centralization cost (for now)
• and a warning in console pointing to docs, so there's a thread to pull on in the cases where it doesn't work

Potential follow-ups:

• Expand the Public Gateway Checker page/repo to cover these types of nodes
• Work w/ collab partners to run these servers, add to above list
• Have js-ipfs include a set of vetted community servers, rotate on node start, or other heuristics (eg RTT)

[achingbrain]

Completely pull ideas out of thin air here, but it would be great if the signalling servers could themselves do some sort of cross-server discovery - use libp2p pubsub to publish handshake offers or peer lists and then relay traffic between browser nodes until they set their own connections up?

Then we could round-robin incoming connections between our own hosted nodes to make it a bit more scalable and even federate with other signalling servers hosted elsewhere?

[vasco-santos]

use libp2p pubsub to publish handshake offers or peer lists and then relay traffic between browser nodes until they set their own connections up?

The signal server is not a libp2p node, which complicates things here a bit.

We have been talking about having the distributed signalling implemented in the relays and I think the time needed to update the star servers properly would be better used to do this on top of the libp2p relay. This has been discussed in the past but we never had progress with the spec for this.

[achingbrain]

The signal server is not a libp2p node

I know, but it could be. That would have been an ace hack week project. Maybe next time..

[Gozala]

but it would be great if the signalling servers could themselves do some sort of cross-server discovery - use libp2p pubsub to publish handshake offers or peer lists and then relay traffic between browser nodes until they set their own connections up?

Me and @hugomrdias created a pitch towards this end protocol/web3-dev-team#43, would be wonderful we all could collaborate to get it to a state where we can submit it.

P.S.: Me and @hugomrdias found that doing live collab on hackmd is a most productive way to get it done. Happy to orginize a call so we could attempt to do it.

[Gozala]

One other thing to consider here that there is no WebRTC in the worker threads, so browser config would have to check if WebRTC is available in the context before enabling it.

[lidel]

Some updates from past two weeks:

• /dns4/wrtc-star.discovery.libp2p.io/tcp/443/wss/p2p-webrtc-star is offline and deprecated
  • I've updated docs to point at new ones in https://github.com/ipfs/js-ipfs/pull/3571/files
• FaultTolerance.NO_FATAL did not work correctly with webrtc-star, but @vasco-santos fixed that in fix: transport manager fault tolerance should include tolerance to transport listen fail libp2p/js-libp2p#893
  • https://share.ipfs.io now runs with FaultTolerance.NO_FATAL and two signaling servers:
    https://github.com/ipfs-shipyard/ipfs-share-files/blob/54881be02bbc35fb4b358020905823cab7c5cf41/src/lib/libp2p.js#L17-L18

Given that we already run two nodes which gives us basic redundancy + are able to keep things working even when centralized signaling is down, I am supportive for enabling WebRTC by default but only if we print annoying error to the browser console like this:

[production warning] this js-ipfs instance uses default centralized signaling service at dwebops.pub, which has limited capacity. To ensure best user experience switch to self-hosted signaling service: <LINK TO DOCS, eg. https://github.com/libp2p/js-libp2p-webrtc-star/blob/master/DEPLOYMENT.md>

This way people have "just works" experience in dev, but there is hard incentive to self-host.
In my experience shaming devs by printing to console.error is quite effective :^)

Thoughts?

[Gozala]

Given that we already run two nodes which gives us basic redundancy + are able to keep things working even when centralized signaling is down, I am supportive for enabling WebRTC by default but only if we print annoying error to the browser console like this:

I think using separate signaling servers has downside of fragmenting a network, maybe instead of suggesting to switch to own signaling we should instead incentivize to adding more signaling nodes instead ? Although I'm not sure if multiple signaling nodes would just split network randomly or will allow to create bridges across them, we would want a later.

Long term I think we should really think about how to enable teams to expand the infrastructure without fragmenting the network by product. I think we should aspire to empowering users to choose a provider as opposed to dev teams prescribing it.

[phillmac]

It seems like the existing servers are very hit and miss, they regularly cause

Uncaught (in promise) AggregateError: 

    Error: peer is not available

Whatever we do we need to prioritise stability.
I've had this error on private servers too, so not sure if it's particularly related to the public servers.
Just thought I'd put in my 2¢ from the point of view of a user to explain how difficult it is to get js-ipfs configured properly, the flakiness makes it exceptionally hard to diagnose what's even the issue here.
See orbitdb/orbitdb#873 (comment)

[SgtPooki]

related: libp2p/js-libp2p#1478

[SgtPooki]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterward (see #4336).

I believe this is done now thanks to https://github.com/ipfs/helia/blob/main/packages/helia/src/utils/libp2p.browser.ts