RFC: Do not return string CIDs from core

[alanshaw]

The following core API functions (in JS at least) return multibase encoded string CIDs:

• bitswap.wantlist
• bitswap.stat
• block.stat
• block.rm
• add
• files.ls
• files.stat
• object.stat
• pin.add
• pin.rm
• pin.ls

Core should not make any assumptions about the what base encoding we'd like our CIDs in or even if we want them encoded as strings. They should all return CID instances.

This would make these APIs consistent with the other APIs and would save a bunch of CID -> string -> CID conversion that's happening at the moment and all the overhead that brings with it.

Thoughts? @achingbrain @hugomrdias @daviddias @Stebalien

[Stebalien]

This is talking about the CoreAPI, not the HTTP API, right? If so, absolutely (well, mostly). Go actually returns special "path" objects in many cases.

[achingbrain]

I am pro this idea. The amount of times we go back and forward between buffers, strings and CID objects in a call across js-ipfs -> js-ipfs-mfs -> js-ipfs-unixfs-*porter -> js-ipld -> some-blockstore is mind-blowing.

ipfs-inactive/js-ipfs-unixfs-exporter#7 is leaning in this direction too.

[hugomrdias]

I also agree 100%

[daviddias]

💯