Discover and use existing ipfs api if available

[olizilla]

Using an in-process ipfs node that's only running for the duration of the install should be avoided if possible. We could check for a repsonsive ipfs api on the default port and use it where available.

[achingbrain]

Can’t we use MDNS to discover a local node instead of using the defaults?

[olizilla]

Good point. Have updated the title to be more about "what" not the "how".

[olizilla]

of note, I think we want to discover an api we can use, not just that there is a node nearby... we could mdns to discover "nodes on this network" but I'm not clear on if it would be a good way to discover "there is a node on this machine with an api you can talk to"

@achingbrain do you thoughts on how it might work?

[fsdiogo]

We should use the ipfs-provider lib to find an available node and use it. If there is none, it can spawn an in-process JS one.

Should we still keep the option to spawn a node using ipfsd-ctl?

[achingbrain]

We should use the ipfs-provider lib to find an available node and use it

Doesn't look like ipfs-provider does an MDNS query? The only strategies is uses that could succeed here are a preconfigured http api or starting it's own daemon which I don't think gives us anything we don't already have?

I'm not clear on if it would be a good way to discover "there is a node on this machine with an api you can talk to"

You get the hostname/IP address of the advertised service back, if it's a local address it should be game on - is that enough?

[fsdiogo]

Doesn't look like ipfs-provider does an MDNS query?

Yes, it does not.

I've opened PR #113 to clarify my intentions.