Why new CIDv1 address can't access?

Help
, ,
1

SOURCE:
https://ipfs.eternum.io/ipfs/QmX38QX8MRWfkJUQHa8Hkfx59TpDCKB4PAUmP14TdTLjyB
USE:

ipfs add --cid-version=1 -q test.jpg

I got this, and no work!:
bafkreifqy5ke5bfodkucny5kz636mfrgurc35ood7aeixtnzg3gzp2isxe
/ipfs/bafkreifqy5ke5bfodkucny5kz636mfrgurc35ood7aeixtnzg3gzp2isxe

AND THEN
USE:

ipfs cid base32 QmX38QX8MRWfkJUQHa8Hkfx59TpDCKB4PAUmP14TdTLjyB

I got this, and work!:
bafybeiebhqfwzxjqmfsw3dqghb4zxacttsb2pfjvislapwpzh74cvjfzxi
/ipfs/bafybeiebhqfwzxjqmfsw3dqghb4zxacttsb2pfjvislapwpzh74cvjfzxi

2

Hm. This is really confusing.

Enabling CIDv1 (on go-ipfs, at least) automatically enables the “raw
leaves” feature. You can disable this with --raw-leaves=false.

Alternatively, you can say “add this file with all the default options
but return V1 CIDs” by passing the --upgrade-cidv0-in-output flag.
This flag is valid for all commands so, if you want CIDv1 everywhere,
you can alias ipfs to command ipfs --upgrade-cidv0-in-output.

The idea was that enabling CIDv1 should also enable all the fancy
features that CIDv1 supports. In this case, “raw leaves” stores the file
chunks as raw blocks of data instead of wrapping these blocks in
additional metadata.

Are you interested in making a PR to the ipfs add command to document
this behavior?

1 Like
3

So, you mean the CIDv1 is not ready yet? Maybe I should use CIDv0 right now?

4

So, CIDv1 itself is ready. However, we’re not ready to switch over to
CIDv1 by default as it changes the resulting hashes and we have quite a
few more changes we’d like to make.

Basically, use --cid-version=1 if you’re fine with new hashes and want
to use the latest-and-greatest features. Use --upgrade-cidv0-in-output
if you just want the output CIDs to be CIDv1.

5

Thanks for replying my question.

6

Related?