Proposal: Move CLI & HTTP API + HTTP Gateway to a separate repo (aka IPFS Daemon)

[daviddias]

With this issue, what I'm effectively proposing is to give a Secondary role to the Daemon Implementation in JavaScript. The goal being to focus on the Core Implementation, it's API and it's robustness.

Discuss :)

[alanshaw]

I’m +1 on this for many reasons, but maybe not the same things you’re trying to solve?

[oed]

As someone who is only using the core api directly in browsers this makes a lot of sense 👍

[daviddias]

The development of the Daemon, the HTTP API and the CLI in parallel to the JS Core Implementation in JS was done in the early days so that we could use the same tests that go-ipfs has to test the JS Core implementation robustness. We have exhausted that benefit a long time ago and nowadays it seems that doing all of it in the same pot is mostly a distraction.

Separating them will put the JS Daemon (HTTP API + CLI) in the back burner, focusing our attention on the Core implementation (which has the primary goal of being a full and 100% working implementation of the protocol, as highlighted at https://js.ipfs.io)

[SahidMiller]

Great! I need this for implementing IPFS CLI in the browser using JQuery Terminal.

I had to hack it to where I am today and learn way too much about webpack at the same time to get it working. (I'm not a fan. 😢)

I suspect the same for reusing the HTTP API for folks wanting to use in the browser (or extension) with LibP2P instead of HTTP while largely keeping the same code.

It's hard to communicate how much of a huge boon it'd be for us front-end folks for this tiny amount of effort from the back-end! There's many useful features packed into IPFS Core and these interfaces (CLI and HTTPish) are a huge help to get started fast in the browser while we're building up our pretty UI's!