SHA-512/256 in the documentation might result a bit ambiguous

[lapo-luchini]

Your homepage implies in its examples that "SHA-512 (256 bit)" is the truncated version of SHA-512, and that's pretty clear in the 0x1320 header, but since there are a few instances (e.g. BouncyCastle's "SHA-512/256" cipher, also BSD tool /sbin/sha512t256) that use a similar name for FIPS 180-4 implementation of SHA-512/t, I would suggest adding a note regarding that (and, maybe, even add that cipher to the multihash cipher table with his own number?).

“Simply truncated” SHA-512 hash, as in your current documentation:
52eb4dd19f1ec522859e12d89706156570f8fbab1824870bc6f8c7d235eef5f4
FIPS 180-4 implementation of SHA-512/t:
006fff7ca0bd5b4a5b01706525ca739e63bf9dbdced6da91911d71b42667ba7f

[Stebalien]

Want to take a stab at disambiguating this in on the website (PR against: https://github.com/multiformats/website/blob/master/content/multihash.md)?

We could also consider adding a new hash function for SHA-512/t but I'd wait for someone to need it first. edit: changed my mind, PRs welcome!

[lapo-luchini]

FIPS 180-4 (section 5.3.6) actually defines a generic way to have SHA-512/t for any t < 512, t ≠ 384 but adding them all is probably overkill, the sub-sections 5.3.6.1 and 5.3.6.2 exemplify SHA-512/224 and SHA-512/256, it would probably make sense to add those.
edit: Nah, why making arbitrary decisions like that, we can use "high values" just like in existing Blake2.
Should I file the PR here or in multiformats/multicodec? (I see the last additions are merges from there)

[Stebalien]

File one against multiformats/multicodec. We really should remove the table here. Pick something in the 2-3 byte range.

FYI, such a PR may take a while to get merged as it'll take time to review and isn't really a priority (although simply having a PR open will help us track progress). Just wanted to warn you.

[DonaldTsang]

Can the same issue be applied to SHA3-512/k?

[Stebalien]

We can but we'll need to define a range, again. Also, does anyone actually use sha3-512/k? I'm really not seeing why these specs aren't just truncating hashes.