ipfs-inactive/interface-js-ipfs-core

RFC: Do not return string CIDs from core

alanshaw opened this issue · 4 comments

alanshaw commented

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 commented

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 commented

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.

  • 👍2
hugomrdias commented

I also agree 100%

  • 👍1
daviddias commented

💯