Windows support

[Mithgol]

JS IPFS API version 11.1.0 requires peer-id@^0.8.0, which requires libp2p-crypto@^0.7.0, which requires node-webcrypto-ossl@^1.0.7.

(Additionally, JS IPFS API version 11.1.0 requires peer-info@^0.8.0, which requires peer-id@^0.8.0, which requires libp2p-crypto@^0.7.0, which requires node-webcrypto-ossl@^1.0.7.)

However, node-webcrypto-ossl@^1.0.7 contains a binary addon and thus that package (and its dependents, and dependents of its dependents, and ultimately JS IPFS API version 11.1.0) cannot be installed (by npm install ipfs-api) on Microsoft Windows unless Microsoft Visual Studio and Python are both installed and setup beforehand (they are required for node-gyp to work).

These requirements are introduced by the latest minor version (the previous JS IPFS API, version 11.0.1, does not contain any binary dependencies).

These requirements are somewhat huge (particularly Microsoft Visual Studio) and also sometimes their installation becomes problematic or impossible (see, for example, the list of open issues about the windows-build-tools npm package).

Therefore these requirements should at least be mentioned on the “Releases” page (in the changelog) because otherwise users will encounter them in their consoles as a quite cryptic (and sudden) error such as the following:

(This particular error is apparently caused by having Microsoft Visual C++ 2010 Express installed without the support for the 64-bit platform where node-gyp currently requires a more recent version of build tools, made in 2015, and with the support for the 64-bit platform corresponding to the 64-bit Node.js.)

Please also consider getting rid of that dependency (node-webcrypto-ossl@^1.0.7) if it is possible. Having a binary addon is, most likely, preventing JS IPFS API from being browserified/webpacked and run in a web browser. I believe these browsers won't run a Node.js binary addon until a huge technological advance happens (such as a fabulous JavaScript-generating cross-compiler or a sandbox for Node.js addons in browsers).

[egasimus]

👍

[daviddias]

That is a webcrypto polyfil for Node.js specifically, in the browser, node-webcrypto-ossl is not loaded as the Browser supports WebCrypto natively:

See:

• https://github.com/libp2p/js-libp2p-crypto/blob/master/package.json#L6-L11
• https://www.npmjs.com/package/node-webcrypto-ossl

This is what enabled crypto to be way much faster in js-ipfs/js-ipfs-api and reduce the bundle size to almost 50% in js-ipfs-api, since we don't have to inject JS to run crypto anymore.

The big issue I see, is the fact that js-ipfs-api requires more setup if you are in windows, which is unfortunate and I would expect that would be something that today people wouldn't have to deal with in Node.js.

We need:

• Obviously find a solution for this build problem (prebuilt the binaries of node-webcrypto-ossl?)
• Add AppVeyor and Windows automated testing to this library, so that we don't get bitten in the future by things like this.

[Mithgol]

Thanks, now you've made it clear that the problem is Windows-only and thus I have no reason to worry about browsers.

But then it's alright, I guess, because on Windows node-webcrypto-ossl devs seem to have already considered pre-building their binaries (as seen in PeculiarVentures/node-webcrypto-ossl#69) using node-pre-gyp (and maybe also node-pre-gyp-github if they eventually decide, which seems likely, that GitHub releases are better than Amazon S3 storage).

That's the right way, and thus their chances of success are high, and thus I've decided to wait (staying on the previous JS IPFS API, version 11.0.1) in a hope that they do that eventually.

[Mithgol]

For future references: Electron is also affected, and thus there's a search for alternatives → libp2p/js-libp2p-crypto#38.

[egasimus]

For the record: Mithgol is on GitHub and building interplanetary Fidonet in Node.js, wow! Good to see a living legend of the Runet picking the best platform out there for his work :-) Rock on dude.

[daviddias]

@Mithgol this PR (merged and released) libp2p/js-libp2p-crypto#42 should have solved the issues you were getting in Electron, at least @haadcode reported that now it is working for orbit (I also tested).

@dignifiedquire @victorbjelkholm you did the set up for go-ipfs to be tested on Windows, I believe. What about getting AppVeyor for js-ipfs-api?

[victorb]

@diasdavid

What about getting AppVeyor for js-ipfs-api?

Part of this quarters milestone is to evaluate a CI system that works across platforms that we can use for all projects. I'll make sure to include that in the evaluation and try it out.

In the meantime, if AppVeyor is the simplest way to test on windows, we should set that up.

[dignifiedquire]

I've used AppVeyor before and set it up for go-ipfs. It's pretty sweet for window CI

[Mithgol]

IPFS API has again become installable on Windows systems lacking their build tools.

Having confirmed that, I am going to close this issue instantly. (I might reopen it later but only if the seemingly installed IPFS API still misbehaves for some installation-related reasons on Windows.)

[daviddias]

Thank you @Mithgol ❤️

[Mithgol]

Version 12.0.2 is fine and reliable so far, thanks; @dignifiedquire's idea of moving node-webcrypto-ossl to optionalDependencies worked like a charm, and we all are quite lucky to have a binary dependency that can be replaced by only a slightly worse JavaScript alternative. (Unlike, for example, node-sqlite-purejs or opendatabase which both perform much worse than sqlite3 that they try to replace.)

[dignifiedquire]

very happy to hear that things are working for your @Mithgol 👌