Can only publish to an IPFS daemon running on localhost:5001

[aschmahmann]

We create an IPFS HTTP Client here https://github.com/ipfs/distributions/blob/7d79fddb8dee3fda74a5b0728da8478db1b2f97d/scripts/dist.js#L23 which per the examples uses the default local go-ipfs port https://github.com/ipfs/js-ipfs/tree/master/packages/ipfs-http-client#example.

It would be great if this could use the IPFS_PATH environment variable to attempt to locate the API file which will have a multiaddr in it and then pass that multiaddr into the HTTP client.

1. Read environment variable
2. Read API addr from file https://github.com/ipfs/go-ipfs-http-client/blob/3af36210f80fb86aae50da582b494ceddd64c3de/api.go#L70
3. Convert multiaddr into IPv4/IPv6 URL and pass it into the client

It may even be worth upstreaming these few lines of code into the HTTP Client as an alternative construction option (WDYT @achingbrain)

[lidel]

@aschmahmann we triaged this as P3, but lmk if its blocking you on anything.

ps. http-client library accepts both URL and Multiaddr these days: https://github.com/ipfs/js-ipfs/blob/00fd709a7b71e7cf354ea452ebce460dd7375d34/packages/ipfs-http-client/src/lib/core.js#L32

[aschmahmann]

ok, so just reading the environment variable and related file then. It'd be nice to fix this since it's probably just a few lines of code, but it's operationally not too hard to work around once you know the issue is there 😄.

If someone decides to do this should it just be done in this repo or upstreamed to the http client?

[lidel]

I could open upstream PR so ipfs-http-client running in Node could leverage presence of process.env.IPFS_PATH for improving the default behavior, but it should be ignored in browser – @achingbrain does this sound like something you want in ipfs-http-client or should I open PR here instead?