feat: default new repos to CIDv1#8185
Open
lidel wants to merge 2 commits into
Open
Conversation
lidel
force-pushed
the
feat/puts-return-cidv1
branch
from
ffbe755 to
4a76f6e
Compare
lidel
changed the title
This was referenced Apr 8, 2022
This comment was marked as outdated.
This comment was marked as outdated.
lidel
force-pushed
the
feat/puts-return-cidv1
branch
from
4a76f6e to
4d6cd50
Compare
lidel
changed the title
lidel
force-pushed
the
feat/puts-return-cidv1
branch
from
4d6cd50 to
0fe289a
Compare
lidel
force-pushed
the
feat/puts-return-cidv1
branch
from
0fe289a to
c087725
Compare
New `ipfs init` applies the unixfs-v1-2025 (IPIP-499) import profile, so fresh repositories produce CIDv1 base32 instead of CIDv0. Existing repos are untouched: no migration and no repo-version bump, so upgraded nodes keep producing the same CIDs. - config: profiles are named via ProfileUnixFSv12025 / ProfileUnixFSv02015; the values used when an Import.* field is unset are LegacyFallback* consts, kept at CIDv0 so existing repos are unchanged and the name marks them as migration-only fallbacks - fresh repos are CIDv1 end to end: MFS root, self-IPNS empty dir, and seeded init docs follow the configured import profile - UnixfsAPI.Add honors the node's Import config, so every import path (direct callers, gateway, client/rpc) produces the repo's default CID version, not just `ipfs add` - CidVersion and raw leaves resolve as a bundle: the config's raw-leaves default applies only when the effective CID version matches the config's, so requesting a different version with --cid-version or a non-sha2-256 hash uses that version's natural leaves (CIDv1 raw, CIDv0 dag-pb); --cid-version=0 with --raw-leaves, or a config pairing CidVersion=0 with UnixFSRawLeaves=true, is rejected - client/rpc: Add follows the daemon's configured CID version instead of always sending CIDv0, and forwards the max-links and HAMT-fanout options - daemon: warn once when a repo still relies on implicit UnixFS import defaults, pointing to the two IPIP-499 profiles - legacy sharness pins the unixfs-v0-2015 profile to keep its CIDv0 fixtures Closes #4143
lidel
force-pushed
the
feat/puts-return-cidv1
branch
from
c087725 to
d6b83fc
Compare
Temporary. The published @helia/interop still expects Kubo's old CIDv0 / 256 KiB import defaults and fails against the new unixfs-v1-2025 default, so build it from the PR branch that adapts the suite (ipfs/helia#1083). Revert this commit once that PR ships to npm.
This was referenced Jul 9, 2026
lidel
commented
Jul 9, 2026
| if: steps.helia-cache.outputs.cache-hit != 'true' | ||
| run: npm install @helia/interop | ||
| # Recurring @helia/interop regression: the published .aegir.js is unusable | ||
| # from inside node_modules, in one of two ways. |
Member
Author
There was a problem hiding this comment.
- revert this if/once fix: pin kubo interop node to unixfs-v1-2025 helia#1083 lands
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Making CIDv1 (base32
bafy...) the default has been tracked in #4143 for years, and the groundwork already landed: both CID versions work throughout, the CLI and gateway render base32, and Kubo 0.29'sImportconfig (#10421) together with IPIP-499'sunixfs-v0-2015/unixfs-v1-2025profiles pin the parameters so any implementation can reproduce the same CIDs. The one remaining gap was the default itself:ipfs initwrote noImport.*, so new repos fell back to CIDv0Qm....Some users also lean on CIDs as if they were deterministic hashes. That is a misunderstanding of what a CID is, but breaking them isn't the goal, so existing repos need agency to move to CIDv1 on their own schedule.
Fix
ipfs initnow applies theunixfs-v1-2025profile to the config it writes, so a fresh repo produces CIDv1 everywhere. This is deliberately the least disruptive way to flip the default:ipfs initwrites, not a code-level fallback. A pre-existing repo with empty or absentImport.*still resolves to CIDv0 exactly as before, with no migration and no repo-version bump.ipfs add:ipfs files, the MFS root, the gateway, and theclient/rpcGo library all produce the configured CID version. Requesting a version explicitly (--cid-version, or a non-sha2-256 hash) uses that version's natural leaves; contradictions like--cid-version=0 --raw-leaves, or a config pairingImport.CidVersion=0withImport.UnixFSRawLeaves=true, are rejected rather than emitting a surprising CID.Import.*is the single source of truth, including whether the startup notice appears. If any CID-profile field is still unset,ipfs daemonprints a one-time notice nudging the operator to pin a profile; once explicit, it stops.unixfs-v1-2025;ipfs init --profile unixfs-v0-2015keeps CIDv0; existing-repo operators are nudged to record their choice rather than lean on an implicit default that could shift across releases.This respects user agency and avoids breaking legacy datasets, while making CIDv1 what new users get out of the box.
References
unixfs-v0-2015andunixfs-v1-2025profiles this PR applies.Importconfig section; #11148 added its IPIP-499 profile fields.Demo
A fresh repo now defaults to CIDv1.
ipfs initwrites theunixfs-v1-2025profile, soipfs add,ipfs files, and the MFS root produce base32bafy.../bafk...out of the box instead ofQm...:Existing repos are untouched. A repo whose
Import.*is empty or absent keeps producing the exact same CIDs. The only new thing its operator sees is a one-time notice atipfs daemonstartup, until a profile is pinned:Once the operator applies a profile (or runs
ipfs init --profile ...on a new repo),Import.*is explicit and the notice stops.TODO