digest: promote blake3 to first-class digest #66
Conversation
stevvooe
force-pushed
the
blake3-first-class
branch
from
66e27ab
to
1728461
Compare
|
oh beans, a rebase is needed |
stevvooe
force-pushed
the
blake3-first-class
branch
from
1728461
to
1367d1e
Compare
The dual module approach for blake3 was slightly awkward. Since it provides similar usability with a massive bump in performance, it's extremely likely to land as a registered algorithm in the image-spec. This PR removes the secondary module, which made it difficult to test as a unit. This may break users who are using HEAD versions of the package. For a new release, this will be backwards compatible. The other drawback is that the zeebo/blake3 will now be a dependency but this can be replaced transparently by the standard libary in the future. In addition to promoting blake3, this makes a few style adjustments to be in line with Go's style guidelines. Signed-off-by: Stephen Day <[email protected]>
stevvooe
force-pushed
the
blake3-first-class
branch
from
1367d1e
to
b941ada
Compare
I'm not against this, but I'm not sure we have reached the consensus on the algorithm name. Is there any actual implementation that has been already using blake3/b3-256/whatever else? |
|
Since blake3 supports multiple digests sizes it seems to me that "blake3" without the digest size (e.g., "blake3-256") is a bad choice for a name. Furthermore, it makes sense to register the 512 bit algorithm as well to have the same collision resistance as SHA512 that you already have registered. "blake3-512" or "b3-512" along with either "blake3-256" or "b3-256" seem to make the most sense for names. This is not a binary compact format like multihash so I favor spelling out "blake3" instead of using "b3". That is my two cents for what it is worth. |
|
since the library you've pulled is is defaulting to 256bit, I think going with @ktarplee is a fine idea. And optionally we could also add "blake3-512" |
|
Do we want to pick this up again? Do we have consensus in the spec yet? |
|
Is there any existing user of blake3 in OCI? |
The dual module approach for blake3 was slightly awkward. Since it
provides similar usability with a massive bump in performance, it's
extremely likely to land as a registered algorithm in the image-spec.
This PR removes the secondary module, which made it difficult to test as
a unit. This may break users who are using HEAD versions of the package.
For a new release, this will be backwards compatible. The other drawback
is that the zeebo/blake3 will now be a dependency but this can be
replaced transparently by the standard libary in the future.
Signed-off-by: Stephen Day [email protected]