Strange behaviour without IPFS Companion

When using the app with IPFS Companion everything works great 🌟

But a simple app like this should require the minimum amount of setup, that being said it should work out-of-the-box with just an IPFS daemon running.

Something strange is happening. Steps to reproduce:

1. Disable the IPFS Companion if it’s active
2. Fire up an IPFS daemon in the terminal
3. Start the app and upload a single file – it should upload successfully and generate a share link
4. Try to upload another file – it uploads but it doesn’t generate another share link as it should (and does with Companion) because the request hangs forever:

http://127.0.0.1:5001/api/v0/object/patch/add-link?arg=QmPvs3XyQqFY8sprbS6A18EqCS1b6A2FwKL8tx4DEjVRUD&arg=package.json&arg=QmdXb9kCfLv4bGHRiiFStC66JSH36Gr2y7j7hW9cnrZqUm&stream-channels=true

The problem should come from this func: https://github.com/ipfs-shipyard/ipfs-share-files/blob/3d8c417ffc0c2ababd771e1277afbecd851e1a55/src/lib/files.js#L47-L56

I can’t understand why it works with Companion & it works the first time the func is called, it generates the share link. But when calling again it hangs. It also happens if you try to upload multiple files the first time, I think there is something wrong when creating the new unixfs-dir and/or adding links to it.

Ideas? @ipfs-shipyard/gui

[lidel]

AFAIK we can’t fix it from the app itself: website’s JS can’t set Connection nor Expect headers 😦 However, I’ve added a new workaround for go-ipfs issue (https://github.com/ipfs-shipyard/ipfs-companion/pull/562) to IPFS Companion. When merged, it will finally fix issue under Chrome if user has our extension enabled.

See the PR for more details.

[lidel]

Yup, this is no longer relevant as we deprecated window.ipfs and will use js-ipfs running on the page itself.