Irakli Gozalishvili

> Sync version, do we need to work on one as well to cover all of this? Yes, I just left out to reduce noise > Is that going to...

@mikeal I recall your primary argument was that lot of node utils would take either and would write into `ArrayBuffer` just as if it was `Buffer`. However now that I...

Thanks @rvagg for going through and providing, feedback. It really helps, especially because I had been debating some of the decisions that you've called out here myself. I'll respond to...

> Yes, I think separating them might be the better option, and maybe the API challenge can be avoided by not performing the composition action on the `BlockCodec` but as...

I think that jQuery style APIs that take anything leads to poorly designed interfaces and leaky abstractions. Everything ends up a parser trying to infer what the input is. Furthermore...

I think not having `CID.toCID` pushes to a more disciplined approach: - Input received on the wire needs to be decoded via `CID.decode` - Input received from user input (CLI,...

> On balance I'm on that side too. Although I do worry a lot about what TS is doing to our dependency trees in general, we're now just in a...

> Currently `CID` is at the heart of IPFS (and IPLD obviously), it's the thing that everything needs. So decoupling that would be nice. But I see a future when...

@hugomrdias I'm willing to work on a pull request that removes dependency on buffer in favor of `Uint8Array` but I'd like to make sure that changes would be accepted before...

> IMO, the APIs should **accept** any binary type or view and just convert to a `Buffer` internally if necessary I actually would like to get rid off `Buffer` dependency...