Closed
Description
TLDR
There is no CLI / RPC / Config option to control max DAG width in Kubo when creating a UnixFS DAG.
Users who want to fully control the final CID need to be able to control this.
Details
and iiuc the implicit defaults are different for files and directories:
- For HAMT-sharded directories, the
DefaultShardWidthhere is 256- my rudimentary understanding is this is
fanoutfrom Unixfs spec but has to be confirmed – see Caveats section below
- my rudimentary understanding is this is
- For files,
DefaultLinksPerBlockhere is ~174
ability to pass a static dag width for files could be exposed via ipfs add --help the same way as --chunker and --hash are, but it requires PR against boxo and kubo.
Proposed design
- Add CLI/RPC parameter
dag-widthipfs add --dag-width=Nwith default being defined in config atImport.UnixFSDAGWidth, similar to Import.UnixFSChunker. - Make default in
legacy-cid-v0profile match current default (174?) - Consider going with higher value in
test-cid-v1– perhaps 1024, matching Storacha - This very likely requires changes to
boxoto expose ability to override mentionedDefault..
Acceptance criteria / caveats
- keep current defaults if possible.
- setting
legacy-cid-v0profile should ensure current behavior does not change- we may need separate
Import.UnixFSDAGWidthandImport.UnixFSHAMTWidthjust to make this profile possible.
- we may need separate
- confirm HAMT-directories continue to work with legacy software
- confirm custom dag width is compatible with HAMT-directories, namely, what is the relation between dag width parameter here and the
fanoutofHAMTShardUnixFS node type. if 256 is a hard requirement, keep it. If not, makeImport.UnixFSHAMTWidthfollowImport.UnixFSDAGWidthunless both are set to different values by the user
- confirm custom dag width is compatible with HAMT-directories, namely, what is the relation between dag width parameter here and the