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
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.