Should embedded node use js-libp2p-websocket-star?

[lidel]

As of v2.2.0 the embedded node (js-ipfs) connects to 8 bootstrap servers and.. that is it. Running browserified version of js-ipfs in WebExtension context limits our transport options to websockets and webrtc. AFAIK the latter is not stable enough to be enabled by default.

But does it make sense to provide a websockets transport with a relay point in the middle by default?

js-libp2p-websocket-star PoC

README at js-libp2p-websocket-star states that:

We host a rendezvous server at /dns4/ws-star.discovery.libp2p.io that can be used for practical demos and experimentation, it should not be used for apps in production.

Indeed, if embedded node is started with it (thanks to Node Config on Preferences screen – https://github.com/ipfs-shipyard/ipfs-companion/pull/395):

{
  "config": {
    "Addresses": {
      "Swarm": ["/dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star"]
    }
  }
}

logs show:

Swarm listening on /dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star/ipfs/<PeerID>

and peer count grows above 8 bootstrap servers.

[olizilla]

@lidel I think yes, as a temporary measure. @diasdavid what say you?

[olizilla]

@lgierth ipfs-companion now ships with js-ipfs and will use the browser flavour emedded js node if no external daemon is available. I don't think we have a huge install base yet, but this could start to put more pressure on the gateway. Given the recent infra issues, would you advice against adding ws-star.discovery.libp2p.io to the default swarm config? Do you have any recommendations for the default config we use here?

[ghost]

@vyzo @mkg20001 what's the state of ws-star?

@olizilla ws-star is separate from the gateway, so it's thankfully not affected by the same issues. However there are (or were) scalabality limitations in ws-star which would lead me to say "don't yet", but things might have improved.

Connecting to the same two /wss default bootstrappers should be fine.

[ghost]

scalabality limitations in ws-star

It basically is or was one big bottleneck and single point of failure, but quite some work has been into improving that

[vyzo]

Its days are numbered I hope :)

[mkg20001]

@vyzo @mkg20001 what's the state of ws-star?

https://github.com/libp2p/js-libp2p-rendezvous will add a new discovery mechanism to libp2p.

This thing will be used to build a new ws-star that's hopefully better than the old

[daviddias]

The writing is on the wall, it should be used for demos, not for prod :)

[olizilla]

@diasdavid do you have any advice on the default config that we supply to js-ipfs from ipfs-companion? We'd like to be able to give a better user experience for people not running an external daemon.

[daviddias]

Depends on what you want to achieve at the moment. If the experience is just to add files to IPFS and make them viewable in the gateways, then WebSocket-Star is not needed for that case.

That said, using WebSocket-Star should be risk free as long as you handle the error that will come out when the Rendezvous point is down. If it is down, then you should do a second attempt at starting the node without the websocket-star transport.

[lidel]

https://github.com/libp2p/js-libp2p-websocket-star/issues/61 will make this much more robust:

mkg20001/js-libp2p-websocket-star-multi substantially improves rendezvous server handling by allowing multiple connections and not suiciding startup if one of them is down. This dramatically improves stability and usability and should be the default. The current behavior is broken in multiple not entirely obvious ways, see ipfs/js-ipfs#1619 for details.