Mikeal Rogers

> it (pinner) can either It can only do the current behavior if we refrain from changing the pinner. There’s lots of good ideas in here but they should be...

> CID.fromCID(cid) - Does that even makes sense ? Should there maybe a clone() method instead ? +1 on a `.clone(cid)` method. > CID.fromJSON(SerializedCID) We don’t have a canonical JSON...

> I'm lead to believe otherwise based on the source Hrm... I wonder what this is there for, cause this isn’t even the old canonical serialization :(

Can we just call it `fromString()`? We don’t accept strings that aren’t multibase encoded so...

We actually alias `toString()` to `toBaseEncodedString()` https://github.com/multiformats/js-cid/blob/master/src/index.js#L246 I didn’t know this until I looked through the code, we should probably document this better and make it the recommended API.

This has me thinking a bit. I’d like to unwind this a little and just consider what I’d want the ideal interface to be. This may not work here but...

Keep in mind that `CID` has breaking changes in the `js-multiformats` work. * https://github.com/multiformats/js-multiformats#cid * https://github.com/multiformats/js-multiformats/blob/master/cid.js There is no longer a `.codec` string property, and you can’t instantiate using a...

> What's does the buffer represent there ? It’s the full binary representation of the CID as a Uint8Array. > Different way to frame this issue would be, can we...

> Bridge canonical and class representations. That’s sort of what I assumed we would end up doing. In whatever the communication bridge between the worker is you would need to...

> worker.port.postMessage({ link: new CID(...) }) This implies a requirement that I don’t believe we have. I would assume that these worker processes aren’t just responding to every random message...