Public gateway slow to open uploads made via embedded js-ipfs node

[lidel]

Background

In the past, "quick uploads" via js-ipfs were near-instant because default bootstrap nodes were also the same nodes that provide public gateway.

In recent weeks this changed, and it looks that we are experiencing consequences of separating bootstrap nodes from the gateway function: upload ends with long wait for gateway.

Upstream issue: JS-IPFS now incompatible with ipfs.io gateway ipfs/js-ipfs#1380

How To Replicate

1. Install latest release or beta of our browser extension
2. Switch to embedded node (js-ipfs)
3. Upload a file that was not yet on IPFS (to be sure it was not cached by the gateway)
4. Wait for resource to be opened from the public gateway

Current Behavior

Step 4 takes forever. It is not slow. It just stopped working.

Expected Behavior

Step 4 takes a few seconds max, like it did in the past.

Possible Mitigations

Circuit Relaying

• While basic circuit-relaying is available, a mechanism for discovering relay nodes does not exist yet.
• According to the RELAY spec, for the time being, relay nodes. should be listed in config statically.
• Caveat: Currently a Relay will only work if it already has a connection to the STOP node
  • Based on local experimentation with PoC setup (js-ipfs in browser extension + go-ipfs on locahost/ws as a relay) it works, but preexisting connection to the STOP node is a limiting factor. Especially problematic on go-ipfs, where connection can be garbadge-collected by ConnMgr.

My understanding is that to improve things, we would have to:

1. enable relay on bootstrap servers listed in default config of js-ipfs
2. ensure relays maintain connections to public gateway(s)

Questions:

• Are we able to improve the situation by enabling use of Circuit Relaying in default config?
  • Is there a set of public relays that are safe to be put in default config of js-ipfs shipped with browser extension?
• Is there anything else we could do to improve situation?

[hazae41]

I think it is because there is not enough pairs connected when using the embedded version

[lidel]

Ack. It will take time to get DHT and proper relay discovery, so js-ipfs team is working on a solution that will restore "realtime feel" in browser contexts: ipfs/js-ipfs#1459 / ipfs/js-ipfs#1459 (comment)

As soon it lands in a new js-ipfs release, we will switch companion to that version.