feat: store blocks by multihash instead of CID

[achingbrain]

Updates the ipfs-repo dep to a version that stores blocks by multihash instead of CID to support CIDv1 and CIDv0 access to the same block.

New features:

• Adds a --multihash argument to the cli command ipfs refs local which prints the base32 encoded multihash of each block

BREAKING CHANGES:

• ipfs.refs.local now returns a v1 CID with the raw codec for every block and not the original CID by which it was added to the blockstore

[achingbrain]

Supersedes #2522

[achingbrain]

@aschmahmann could I get a 👍 or 👎 on the cli change please? It would be a shame to ship this and then have go-ipfs implement something different later down the line.

The change is:

• ipfs refs local used to print out CIDs of blocks in your repo
• Now it prints v1 raw CIDs instead
• There's a new --multihash argument to ipfs refs local which prints base32 encoded multihashes instead of the v1 raw CIDs

[aschmahmann]

@achingbrain I'm having trouble finding which issue describes what we agreed on here. This change seems reasonable to me, but mostly because I'm not sure what people are using ipfs refs local for... I recall we use ipfs refs {cid} with the preload nodes but that code path is left unchanged.

Any pointers?

[achingbrain]

The issue & decision is here: ipfs/specs#242 (comment)

Also relevant: ipfs/kubo#6815

[aschmahmann]

Neither of those issues seem to explicitly reference the changes to ipfs refs local. Although I guess it's probably implied by those issues since there may be orphaned (e.g. unreferenced by a pin) blocks that we just can't figure out the CIDs for.

[achingbrain]

I guess it's probably implied by those issues since there may be orphaned (e.g. unreferenced by a pin) blocks that we just can't figure out the CIDs for

Exactly, it's more of a practical implication of dropping the original CID a block was stored by.

[aschmahmann]

Seems reasonable 👍 from me then. If @hsanjuan or @Stebalien have a second to confirm that'd be great, since they've been more involved with this than I have. However, if they're busy then no complaints from me

[Stebalien]

@achingbrain that's the planned change for go-ipfs as well.

[oed]

So does this change mean that all data already stored in an ipfs node will not be retrievable locally when one updates to v0.48?
Is there a data migration strategy that can be used here?

[achingbrain]

No, there should be no change. A blockstore migration takes place when you first start a node running 0.48.0 on a non-migrated repo to convert all the keys so what is currently retrievable should still be retrievable after the upgrade.