Directories are objects that contain a set of hashes. Directories created with versions of IPFS that default to CIDv0 hashes will contain these hashes, right? The directory’s hash is the hash of the hashes it links to. Meaning that the same directory of content will generate different CIDs.
Is there any migration process or compatibility system in place, so that newly created CIDv1 directories will generate a shadow IDv0 directory for backwards compatibility? Otherwise old directory addresses will stop working at some time, even though the content might actually exist in the network under a newer address.
There is no real reason to replace CIDv0 in the case where they work fine.
The current rules is:
If a CIDv0 works (encoding: dag-pb, sha2-256), use CIDv0.
Else use CIDv1.
What happen is that when directories are serialized this rule is used to know which version to use.
You should also note that directories use binary cids, so there is no encoding / base difference.
The only reason directories would contain CIDv1 currently, is if you are using a different hashing function or if you are using --raw-leaves.
Also CIDv1 and CIDv0 of the same data are interchangeable, so it’s like it’s an issue.
The current plan is to support both for forever.
And since CIDv0 is compatible with CIDv1 just use whatever you want to use.
(the only except where you MUST use CIDv1 is if you are using alternative hash function or non dag-pb blocks).
And just to add, go-ipfs v0.11.0 enabled UnixFS sharing by default which will result in different CID’s but I don’t know what version those might be.