opencontainers
Consider adding Blake3 to registered types
I think we should consider adding blake3 to the registered types (https://github.com/opencontainers/image-spec/blob/79b036d80240ae530a8de15e1d21c7ab9292c693/descriptor.md#registered-algorithms). I propose the prefix b3-256.
We can add support for it (though b3 has many configurable hash lengths -- how do we pick the best one?), but I do think we also need to work on making sure that tooling which generates images supports mixed-digest images (and maybe that should be done first). It's not just a matter of being able to handle different hashing algorithms, it's that you need to have a way of either regenerating all hashes in an image tree with different digest algorithms or otherwise determining what is the best hash algorithm to use given an existing image that you're creating a modified version of.
For instance, given a descriptor tree full of SHA-256 digests you probably want to use SHA-256, but if there's a SHA-512 in there which should you use for new digests when creating a new image? Maybe you want to opt for the newest algorithm in use by an image digest tree? Either way I think most tools already don't handle SHA-512 in the most ideal way, so we need to work on that.
And finally it would be nice if we had a way of not having to duplicate the same underlying data if the hashing algorithm referring to it is different (layers being the most important example of this). But then again, tools can also be sufficiently clever about this (store an out-of-spec lookup table which knows the hash of each object under multiple hashing algorithms).
Also this will need probably need a https://github.com/opencontainers/go-digest PR first?
There seemed to be a circular nature between go-digest and image-spec. Mostly I'm starting the issue so I can get blake3 added to go-digest, but the process by which you get new hashes added to go-digest is to first add get them registered here.
I also wanted to start the conversation of what the prefix should be. I suggested b3-256 in my initial issue description, because b3 = blake3, 256-bit, where 256 bits is the default b3sum output.
I added a proposal to add blake3, where the default hash length is 256-bit as suggested in the spec.