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

[aschmahmann]

We create an IPFS HTTP Client here

distributions/scripts/dist.js

Line 23 in 7d79fdd

const ipfs = IpfsHttpClient()

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?