`nix hash to-sri` could infer hash type from hash length about nix HOT 3 OPEN

It's only unambiguous right now because we have only one hash algorithm for each byte length. But #10600 adds BLAKE3 support, which has the same length as SHA256. So nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5 would no longer be unambiguous.

from nix.

I don't think it's unreasonable for it to throw an error in that case that says something like can't determine between BLAKE3 and SHA256, please explicitly specify. Given that the number of algorithms is probably not something that is going to scale massively, I think it's worth considering.

from nix.

Is it planned that 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5 as a BLAKE3 hash would ever be output in that format? Could new hash algorithms exclusively be output in SRI format, to avoid the ambiguity? (if you manually nix hash to-base32 a BLAKE3 hash, that seems like your own fault)

Alternative semi-serious proposal:

$ nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5
warning: ambiguous input format (use --type to disambiguate), possibilities:
sha256-Bc4C1cOOHdWkw2mHn3Q/2fcKuyCFDvOq1jLee2WPsyI=
blake3-Bc4C1cOOHdWkw2mHn3Q/2fcKuyCFDvOq1jLee2WPsyI=

I guess the third alternative is "don't use to-sri, use to-base64 and add the prefix by hand" but that seems suboptimal, frankly.

from nix.