Adding blake3 as good hash

[laudiacay]

See title- this is so that IPFS can support verified streaming feature of BLAKE3, as people mentioned in ipfs/kubo#8650

Not sure if you need to do like, a version bump here, so that it can be integrated into new IPFS builds... Let me know how I can fix that/get in line with y'all's versioning.

[laudiacay]

Closes #13 btw

[laudiacay]

@titusz wanna review?

[laudiacay]

I believe I fixed the versions here- before I merge this, we need to get my fixes into go-multihash in (future) version 0.2.1. doing that now.

[laudiacay]

mergeable pending this: multiformats/go-multihash#158

[aschmahmann]

blocked pending confirmation this is ready to go in upstreams

[laudiacay]

Problem: if we do that I’m pretty sure most of the out of the box applications of cool features of blake3 break. Like for sure we’d at least have to modify the bao verified implementation to make the final hash longer then truncated, and it may straight up break other stuff. Happy to add 64 and 128 variants but I don’t think truncation down to 32 is a great answer for this application necessarily?

…

On Wed, Jul 6, 2022 at 10:00 PM Steven Allen ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In validate.go <#15 (comment)>: > return ErrBelowMinimumHashLength } + if pref.MhType == mh.BLAKE3 && pref.MhLength != 32 { We can solve this one of two ways: 1. A refactor. But there's no reason this refactor would need to touch more than the multihash crate. 2. Make the blake3 hasher output "maximum size" digests, then truncate (which go-multihash will already do). What I would do to do so is in github.com/multiformats/go-multihash I would make blake3's hasher produce hashes of the length you are comparing it to. As long as the default blake3 hasher produces, say, 64 or 128 byte hash digests by default, we don't need to worry. go-ipfs will call Sum(data, code, length) which will truncate to the desired length. If the requested digest size exceeds the maximum, we'll get a ErrLenTooLarge error. For now, I'd be in favor of *not* refactoring unless there's a large performance penalty to producing larger hashes. — Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDPMJBURNFU3LLZMBEQHBLVSY24ZANCNFSM52KQP6SA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Stebalien]

Please clarify? A short blake3 hash digest of a file is always a prefix of larger hash digests.

[laudiacay]

Ok lol my bad- I’ll do that, let’s call the max 128

…

On Wed, Jul 6, 2022 at 10:23 PM Steven Allen ***@***.***> wrote: Please clarify? A short blake3 hash digest of a file is always a prefix of larger hash digests. — Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDPMJDDKM2G2WBFTDCY5F3VSY5SDANCNFSM52KQP6SA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Jorropo]

Almost LGTM

[Jorropo]

Replaced by #16