Ipfs cid v1 help me derive cid by hand

Assume that I want to derive ipfs cid v1 version. See

basically, I already did it using ipfs add --cid-version 1 gio.js which gave me bafkreiatqjyjbs7u6gmqzucb4odvia5uhyzyo75c3j6iaard2ouhvu2vbe.

I am checking this so that I want to be able to get the same cid but by hand.

  1. So we start multibase, since it’s base32, from the multibase table, we’re looking at b which has unicode 62. So we start as: 0x62

  2. The next thing is cid-version which is 01. So 0x6201

  3. then comes multicodec which is 0x55(raw), so we have 0x620155. see table

  4. then comes multihash part. It’s sha256 which is 12 and length is 256 bits, ie 32 bytes i.e 20 in hex. so multihash is 1220+hash (see [table])(multicodec/table.csv at master · multiformats/multicodec · GitHub)

So in the end, we’re left with 0x6201551220+hash (you can see hash on here)

When I have this final representation, I base encode it with base32, but don’t end up with the same thing as bafkreiatqjyjbs7u6gmqzucb4odvia5uhyzyo75c3j6iaard2ouhvu2vbe.

The binary encoding of a CID does not include any information about the text encoding.

If you take the following hex 0155122013827090CBF4F1990CD041E3875403B43E33877FA2DA7C800223D3A87AD35509 and encode as base32 you get AFKREIATQJYJBS7U6GMQZUCB4ODVIA5UHYZYO75C3J6IAARD2OUHVU2VBE which is what you would expect.

Adding the multibase prefix you more correctly get:
f0155122013827090cbf4f1990cd041e3875403b43e33877fa2da7c800223d3a87ad35509 is equivalent to bafkreiatqjyjbs7u6gmqzucb4odvia5uhyzyo75c3j6iaard2ouhvu2vbe

Hopefully reading the latest version of the spec document makes this more clear cid/README.md at 603f4570ba051192224dd1a3b131a6ebdd486b4f · multiformats/cid · GitHub.

Hey Adin,

Thank you. I actually understood your first paragraph, but not the second. Why did you add ‘f’ in front instead of ‘b’ and how did adding ‘f’ resulted in the same thing

Sorry if that wasn’t clear what I was trying to point out is that there is a binary and text from.

By even writing 0112... you are implying a hex encoding which when using multibase would use an f prefix (the way you’re using it 0x means the same thing as f)

So the correct comparison of two base encodings of a CIDv1 would be to compare the two multibase encodings.

This is why your comparison by encoding 0x62011120... doesn’t really make sense, the b was supposed to tell you the text encoding and then you tried to use it as hex and reencode it.

Does that make sense?

1 Like