search

ipfs / js-ipfs

IPFS implementation in JavaScript
https://js.ipfs.tech
Other
7.44k stars 1.25k forks source link

Enable WebRTC by default in the browser? #3541

Closed achingbrain closed 1 year ago

achingbrain commented 3 years ago

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 commented 3 years ago

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 :+1: 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 commented 3 years ago

+1 to:

Potential follow-ups:

achingbrain commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/protocol/web3-dev-team/pull/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 commented 3 years ago

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 commented 3 years ago

Some updates from past two weeks:

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/orbitdb/orbit-db/issues/873#issuecomment-812878896

SgtPooki commented 1 year ago

related: https://github.com/libp2p/js-libp2p/issues/1478

SgtPooki commented 1 year ago

js-ipfs is being deprecated in favor of Helia. You can https://github.com/ipfs/js-ipfs/issues/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 https://github.com/ipfs/js-ipfs/issues/4336).

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