Adding js-ipfs support

[dryajov]

NOTE: I don't intend to start a big discussion around this, as I think 1) is relatively low risk, 2) is pretty self evident. This is mostly a brain dump after taking an initial stab at it - but feedback is welcome as I want to make sure I don't miss something obvious either.

Here are some questions that have come up after starting this effort:

1. ipfsd-ctl execs the Go executable and communicates with it over cli (this is natural since it's not a node proces)

   • In order to integrate node ipfs support, we have two options
     • Usejs-ipfs cli
       • The advantage is that we can reuse a lot (how much?) of it the current implementation
       • The disadvantage is that there are differences which could invalidate reusing the current implementation - I feel like until we dig in, we won't have a clear understanding
     • Use js-ips as a library
       • The advantage is that it's a lot simpler to interact with js-ipfs over the library interface
       • The disadvantage is that we implement it from scratch - tho we can pull/copy existing implementations of this from the various available out there

2. using ipfsd-ctl now becomes context aware

   • if ran from within js-ipfs we must likely want the option to use that js-ipfs, this will allow us to test it against itself running as a standalone node.
   • if ran from any other project or standalone, just use the bundled js-ipfs

IRC discussion for background:

09:55 <@dryajov> daviddias: victorbjelkholm: you around? want to bounce a few ideas of you for the ipfsd-ctl stuff… 
09:55 <@victorbjelkholm> yup!
09:56 <@dryajov> basically, for the js daemon, do we want to spawn an external process a la Go? or use the ipfs library directly (basically reusing the factory stuff in js-ipfs)
09:57 <@dryajov> I think it comes down to, which interface is going to be more consisten/stable - cli or library?
09:58 <@dryajov> thats one thing… #2 is:
09:58 <@victorbjelkholm> #1:
09:59 <@victorbjelkholm> could spawn it directly in the process, as long as we expose the http-api so js-ipfs-api will be used for both js-ipfs and go-ipfs, so we can be 100% interface works the same
10:03 <@dryajov> hmm, your right… http-api will give us a consistent interface either way (I was thinking more from ipfsd-ctl internals perspective tho, but voising it out kinda makes the choise obvios :D  - library is way easier to use)
10:03 <@dryajov> your right, http-api will give us a consistent interface either way
10:03 <@dryajov> 👍
10:04 <@dryajov> #2: running inside js-ipfs vs running standalone
10:04 <@dryajov> if running from js-ipfs we want to use _that js-ipfs_ 
10:05 <@dryajov> if running from outside, we just require the bundled one?
10:06 <@dryajov> victorbjelkholm: does #2 make sense, I can elaborate if its too confusing - brain dump at this point
10:12 <kyledrake> hsanjuan let me know when you're ready for me to take a wrecking ball to ipfs-cluster. :)
10:13 <@victorbjelkholm> dryajov: hm, thinking about the internals, way easier to skip the library and spin up process, then it doesn't matter if it's go/js/rust/scheme
10:14 <@victorbjelkholm> then #2 would always run bundled one
10:14 <@victorbjelkholm> the daemon for each language should be as a optionalDependency as well, as you might only use go-ipfs for example
10:23 <@dryajov> victorbjelkholm: hehe… my dilema...
10:23 <@dryajov> for #1
10:23 <@dryajov> tho, we still have differences from go to js cmd and outputs
10:24 <@dryajov> so we can’t reuse %100, but it should be close enough 
10:24 <@victorbjelkholm> yeah, but the startup/shutdown sequence should be the same (ipfs init, ipfs daemon)
10:24 <@victorbjelkholm> the outputs should be standarized at one point as well (maybe we need ipfs-interface-cli)
10:28 <@dryajov> +1 for ipfs-interface-cli...

@victorbjelkholm @diasdavid

[daviddias]

Good notes @dryajov. Let's go by parts.

ipfsd-ctl should enable a user to:

• spawn a js-ipfs daemon
• ✅ spawn a go-ipfs daemon

And also:

• ✅ interact with the daemon through its commands
• ✅ interact with the daemon through ipfs-api

Right now, 3/4 are done. I understand your point that there are differences in the CLI, but that is ok, the first Milestone is to get the interaction through the ipfs-api to work just fine. Anything that is not supported (namely by js-ipfs) will error and the user will be informed (which is fine).

[dryajov]

Anything that is not supported (namely by js-ipfs) will error and the user will be informed (which is fine).

👍

[daviddias]

Work happening at #170