How are the DAG link buffers encoded (js-ipfs)?

First, I’ve added a simple object:

echo '{"simple":"object"}' | ipfs dag put
// zdpuAzE1oAAMpsfdoexcJv6PmL9UhE8nddUYGU32R98tzV5fv

Then, a link referencing this object at /link/:

echo '{"link":{"/":"zdpuAzE1oAAMpsfdoexcJv6PmL9UhE8nddUYGU32R98tzV5fv"}}' | ipfs dag put
// zdpuB2iusYDfFRqouEiWgnzo959JZ5sE4vWruNKhmBahHLxvF

Now, in the javascript ipfs library, when I call ipfs.dag.get('zdpuB2iusYDfFRqouEiWgnzo959JZ5sE4vWruNKhmBahHLxvF')

I’m getting back:

{ link:
   { '/':
    <Buffer 01 71 12 20 cd 16 50 e4 18 a3 e8 04 47 cc 4f f3 01 eb 10 24 5b 15 25 bf fc 8e b4 03 bc 38 53 fb 5f a7 52 f1>
  }
}

Where that link seems to decode to dpuAzE1oAAMpsfdoexcJv6PmL9UhE8nddUYGU32R98tzV5fv rather than the hash zdpuAzE1oAAMpsfdoexcJv6PmL9UhE8nddUYGU32R98tzV5fv.

Edit: Now that I’m looking at it, it looks like we’re just missing the Z. :grin:

That’s because IPFS uses the CIDv1 encoding, which starts with a “multibase” character.
That means that:
zdpuAzE1oAAMpsfdoexcJv6PmL9UhE8nddUYGU32R98tzV5fv and
f01711220cd1650e418a3e80447cc4ff301eb10245b1525bffc8eb403bc3853fb5fa752f1
represent the same hash.
For more info, look here:

@Mateon1 What was throwing me was dpuAzE1oAAMpsfdoexcJ… looked like a different hash at first glance. On the Go version, it resolves to zdpuAzE1oAAMpsfdoexc… I believe this is a tiny bug in the JS implementation.

Arby, when you say “Where that link seems to decode to dpuAzE1oAAMpsfdoexcJv6PmL9UhE8nddUYGU32R98tzV5fv”, are you just doing a .toString?

That value is missing (not really) the multibase value as that is something that only exists on the String version. We don’t return the CID version because that is one more encoding operation.

If you want to stringify it, then use the CID package (https://www.npmjs.com/package/cids) with

new CID(that buffer).toBaseStringEncoded() and you will get what you were looking for :slight_smile:

Let me know if that works for you!

On second thought and checking in with @why, it seems that this can be considered a bug, since the multibase for binary should be there in Buffer mode always. The reason why it all works is because the CID module and ipld-resolver are pretty good at guessing things.

@arby would you like to submit a patch for this? Also, we need some compliance tests https://github.com/ipld/js-ipld-resolver/pull/75