Thanks for submitting the issue @MicahZoltu, sounds like a great enhancement. Can you please also detail on:

I now need to go convert this to CIDv1 before I can use it.

Under what scenarios is this CIDv0 not handled?

Also, sounds like you have good context on what's happening, would you like to create a PR for this issue?

I now need to go convert this to CIDv1 before I can use it.

Under what scenarios is this CIDv0 not handled?

Websites that use local storage/cookies should always use CIDv1 so they get sandboxed by the browser by subdomain. See the big red box on http://docs.ipfs.tech.ipns.localhost:8080/how-to/address-ipfs-on-web/#subdomain-gateway for additional details. Also worth noting that http://docs.ipfs.tech.ipns.localhost:8080/concepts/content-addressing/#cid-versions suggests using CIDv1 if anytime you aren't sure (e.g., a reasonable default).

I have a good handle on the problem/security considerations, but I have never looked at the IPFS desktop codebase so fixing it would be quite challenging for me. 😢 I don't mind getting mentioned on a PR to review, or I'm happy to answer any questions one might have about the situation.

Presumably the API equivalent of ipfs add --cid-version 1 ... needs to be called when adding files, rather than ipfs add .... My hope is that this is something that is relatively easy to address for someone who knows the codebase.

Now that #2402 landed, I think the only remaining surface in IPFS Desktop is the root CID of MFS itself.

By default, it is CIDv0, but IPFS Desktop could upgrade it with ipfs.files.chcid:

$ ipfs files stat /
QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
Size: 0
CumulativeSize: 4
ChildBlocks: 0
Type: directory

$ ipfs files chcid --cid-version 1 /                                                                                                                                                                       

$ ipfs files stat /
bafybeiczsscdsbs7ffqz55asqdf3smv6klcw3gofszvwlyarci47bgf354
Size: 0
CumulativeSize: 4
ChildBlocks: 0
Type: directory

Once upgraded, changing MFS will always produce CIDv1 root.

I think we could do it during startup – check if CID is v0, and if so, upgrade tov v1.

@davidd8 @SgtPooki thoughts?

Im down with updating it to cidv1, but need to look further into gotchas and edge-cases.

Is there a tracking issue for kubo to default to cidv1?

Switching MFS root to CIDv1 should not have any gotchas. Newly created dirs will be CIDv1, that is all.

@SgtPooki Kubo issue for switching to CIDv1 is ipfs/kubo#4143, but tldr

• we not only change CIDv0 to CIDv1, but also switch default from raw-leaves=false to raw-leaves=true
• most of the commands (block put, dag put, refs, name publish) are migrated, only remaining one is ipfs add and MFS root
  • afaik the only reason we did not switch everything to CIDv1 in Kubo yet is priorities/time/resourcing: someone needs to update all the tests where we used hard-coded CIDv0 and raw-leaves=false (I never had time to finish test: ipfs add with CIDv1 as default kubo#8185)
• 👉 the historical UX gotcha around this was that if IPFS Desktop and ipfs add from Kubo use different defaults, users may be confused why they got different CID. I think the times changed, and people in ecosystem are used to different apps having different defaults (e.g. web3.storage defaulting to 1MiB chunk instead of 256KiB like Kubo), and we should not try to keep these things in sync across ecosystem, but instead migrate each system whenever we have time.
  • With this in mind, I think it is fine for IPFS Desktop/WebUI to switch to CIDv1 and even adjust default block size to 1MiB, without waiting for Kubo.

Now that #2402 landed, I think the only remaining surface in IPFS Desktop is the root CID of MFS itself.

By default, it is CIDv0, but IPFS Desktop could upgrade it with ipfs.files.chcid:

$ ipfs files stat /
QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
Size: 0
CumulativeSize: 4
ChildBlocks: 0
Type: directory

$ ipfs files chcid --cid-version 1 /                                                                                                                                                                       

$ ipfs files stat /
bafybeiczsscdsbs7ffqz55asqdf3smv6klcw3gofszvwlyarci47bgf354
Size: 0
CumulativeSize: 4
ChildBlocks: 0
Type: directory

Once upgraded, changing MFS will always produce CIDv1 root.

Is this a button that could be added to the UI on a shorter timeline than changing the default? As an IPFS Desktop user, I don't even know how to get to an IPFS command line on a host with only IPFS Desktop installed, and I would like to be able to recommend this solution to people who don't know how to use a command prompt.

@lidel if this were to be prioritized, does this task list look good?

• Implement chcid in the client libs (both ipfs-http-client and kubo-rpc-client don't do it.
• Migrate ipfs-desktop to kubo-rpc-client
• Implement the upgrade like: feat: default MFS to CIDv1 #2527

Is there something I'm missing?

@whizzzkid sounds about right for ipfs-desktop itself.
I think we still have to update ipfs-webui to import files via ipfs.add with cidVersion: 1 here(?) to have CIDv1 produced when user adds file via GUI (#2402 only applies to import via context menu on Windows).

Changing this for everyone in webui is tricky, as will impact Kubo, which is still CIDv0, and we don't want those users to have different CIDs on CLI and webui.

I think we could make this smart and not hardcode cid version used during import via webui, but base it on the CID version of the MFS root (can be checked via ipfs files stat /, if returned value is not Qm, you know it is CIDv1).

If user's MFS is CIDv1, it is safe to apply the same to files that will be imported there.