Use CIDv1 for all dags constructed by iroh, output string representations in base32 CIDv1

[b5]

A lot of our code is using Base58 CIDv0 (the CIDs that start with Qm). We need to use base32 CIDv1 everywhere (the longer, more annoying looking ones like bafybeieoxkt2hpo26ulnpldsopqmrjsi4iewa53v5slmqejkc4qfbycxpy).

This is only applies to CIDs Iroh constructs. Read operations like iroh get still need to accept & return CIDv0 format when requested.

The CID Inspector is a super useful tool for understanding the format.

We're not massive fans of the UX hit that base32 gives, but we need to be able to copypasta into URL bars, and this is the only modern format that works for such a thing.

Landing this in time for our first release is going to be painful, but let's keep in mind, changing this sort of thing can take years, and even then not fully land.

[ramfox]

We currently use CIDv1 when building our DAGs, but accept reading DAGs from both versions!

[b5]

cool, so this should just be a matter of changing the output format in the iroh package? Anything else missing that you can think of?

[ramfox]

I'm not sure what you mean by that, when you add content using iroh add, the return cid is in CIDv1.

Is there a specific place you've seen CIDv0 that I'm missing?

[b5]

nope. just wanted to confirm this direction & get it on the record. All good!

[lidel]

We currently use CIDv1 when building our DAGs

Are you also enabling raw-leaves when using CIDv1 during UnixFS dag creation?

fysa Kubo (go-ipfs ~0.4) made a decision to make it default for CIDv1 to enables raw leaves.

• CIDv0 always does ipfs add --raw-leaves=false (because there is no codec in CIDv0, we can't have raw blocks)
• CIDv1 allow for raw blocks, so default is flipped, and it does ipfs add --cid-version 1 --raw-leaves=true

iirc https://github.com/ipfs/go-unixfs still produces CIDv0 by default, but if we ever change it toproduce CIDv1, it may also mean enabling raw leaves and changing DAG multihashes.