nix hash to-sri could infer hash type from hash length

[sersorrel]

Is your feature request related to a problem? Please describe.
I'm always frustrated when I run a command like nix hash to-sri and get an error:

$ nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5
error: hash '08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5' does not include a type, nor is the type otherwise known from context

The error message doesn't remind me particularly well what the solution is (--type sha256), but more importantly it's actually entirely possible for Nix to figure out what I meant here. The four documented options for --type are md5, sha1, sha256, and sha512, and only one of those actually works:

$ nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5 --type md5
error: hash '08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5' has wrong length for hash type 'md5'
$ nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5 --type sha1
error: hash '08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5' has wrong length for hash type 'sha1'
$ nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5 --type sha256
sha256-Bc4C1cOOHdWkw2mHn3Q/2fcKuyCFDvOq1jLee2WPsyI=
$ nix hash to-sri 08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5 --type sha512
error: hash '08mkixjpppijssmg63l542xhmxyr7xs9z1v9qfjda7cfqgah5kh5' has wrong length for hash type 'sha512'

Describe the solution you'd like
If it's unambiguous what kind of hash I've passed nix hash to-sri (or any other command accepting a hash), I'd like it to Just Work.

Describe alternatives you've considered
I suppose I can see an argument for not reducing the overall friction of base32 hashes too much, if there is an ongoing effort to stop using them in favour of SRI hashes, but that shouldn't apply to to-sri – that just makes it more difficult to move away from base32 hashes.

Priorities

Add 👍 to issues you find important.

[edolstra]

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.

[imadnyc]

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.

[sersorrel]

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.