Alex Potsides

> I think npm-on-ipfs rewrites the resolved field back to the central registry, This is true, though it rewrites to the `registry.js.ipfs.io` mirror. This is because `npm-on-ipfs` spins it's proxy...

I'm very much a fan of the Robustness Principal here - we should continue to provide an API that accepts strings, buffers, etc (either the constructor or the proposed `CID.from(thing)`...

Not sure I agree - if `CID.from(x)` does the work figuring out what `x` is, then the reader doesn't have to care what `x` is either, only that a `CID`...

As I see it, the problem is you get a `CID` back from another module and you're not sure if it supports the API you expect. Historically a test would...

> Argument could be made that constructor could throw instead of returning null Throwing when it encounters invalid data is exactly what the constructor [does right now](https://github.com/multiformats/js-cid/blob/master/src/index.js#L114). > It does...

You are making requests to `ipfs.infura.io` - I would suggest you check their documentation or contact them directly to find out what is required as this is unlikely to be...

Can you please provide a small reproduction repo? I think this is down to your webpack config - you can see some working config [here](https://github.com/ipfs-examples/js-ipfs-browser-webpack).

Can you try disabling libp2p autodial and see if it still happens? ```js import { create } from 'ipfs-core' const node = await create({ libp2p: { connectionManager: { autodial: false...

This will be fixed by https://github.com/libp2p/js-libp2p/pull/1397 (likely in the next libp2p release, `0.40.x`) so you may want to leave `autoDial` disabled until that ships. When it does you should turn...

Do you have a minimal reproduction that we can run to see the problem?