Why is ipfs url different now?

1

I have recently upgraded to the latest version and I noticed now a hash number is first followed by ipfs.localhost:8080/.

For example before the URL looked like http://localhost:8080/ipfs/Qm...

Now the URL looks like <hash>.ipfs.localhost:8080

The two questions I have are:

  1. What is this new hash? It doesn’t match the CID I get from ipfs on the command line which starts with Qm.

  2. Why does the URL now look like a subdomain starting with this new hash?

2

The changes you observe are based on https://github.com/ipfs/specs/issues/247#issuecomment-614742033

The answer to question #2 is best described here: https://github.com/ipfs/go-ipfs/issues/5982#issue-408601450. That is: by giving each “root cid” a subdomain on its own, you can serve a webapp that is properly secured client-side (by the browser itself).

URLs are case-insensitive, so the original base58 Qm… stuff is a no-go. This is why the different base for the CID encoding. The power of multiformats allows this to be the very same CID, for instance these are all the same thing:

https://gateway.ipfs.io/ipfs/QmQPeNsJPyVWPFDVHb77w8G42Fvo15z4bG2X8D2GhfbSXc
https://gateway.ipfs.io/ipfs/bafybeia6po64b6tfqq73lckadrhpihg2oubaxgqaoushquhcek46y3zumm
https://gateway.ipfs.io/ipfs/f017012201e7bbdc0fa65843fb589401c4ef41cda75020b9a0075247850e222b9ec6f3463
https://gateway.ipfs.io/ipfs/zdj7WXUtkJNFSy7FxXR2L4joW6ceU8EidQCTaS3o1QwX7ALhY

You can play with converting your own cid’s via:
ipfs cid format -v 1 -b <chosenbase> <cid>

to get a list of supported encoding bases:
ipfs cid bases

3 Likes
3

Thank you for the links and explanation. This clears up so much. So just so I understand this. The reason the new CID begin with ba is because it is hashed with sha256 and base32 encoded?

4

The decompositions of

can be seen here ( in the same order ):

5

You could also check out the insanely awesome ProtoSchool | Interactive tutorials on decentralized web protocols

1 Like