Why does ed25519 seem to accept and use 96-byte / 384-bit signatures?
This is likely an artifact of the API used in the specific piece of code you're using. This piece of code follows the NaCl API, which verifies the input as the concatenation of signature and message (sm) and copies the message out of sm into the message buffer m. The NaCl paper explicitly states on p.&nbsp;5 et seq. that this is an intentional design choice. The reason why it "will include extra bytes at the end of the signature" is because these seemingly extra bytes are actually the message that was signed.

Thus they're not actually 96-byte signatures, but rather 64+$L$-byte signatures, where $L$ is the length of the signed message in bytes, and 64 is the length of the actual signature.



Note that it is theoretically possible to have 96-byte signatures specifically, by skipping point compression, as noted on the original Ed25519 paper, p.&nbsp;15, but this isn't the case in the code you're linking as an example.