the canonical form that makes the signature doesn't have it, it's impossible
the purpose of having that value in there is to make validation of the signature faster, because web browsers are slow at doing crypto
Discussion
ie, you can verify the signature, +1, and then you can form the canonical form and hash it +2, it depends on how deep you want to verify
also there is other aspects too, like, when you encode it as binary, you have to decode that, make the canonical form, then hash it, to verify the signature if you didn't store the hash in the binary form as well
but generally a relay checks the signature when it receives it, if valid, accepts it and sends an OK true message back and stores it, it doesn't really have to verify it again, but it also doesn't have to make the canonical form if it keeps the hash in the data, it can just spew out the json, this is also faster
I was going through the verification flow in my head before I wrote the OP, trying to come up with a justification, maybe DoS related, but couldn't come up with anything.
I don't think there's *any* value in validating the signature without also validating the signature is actually signing the contents, otherwise you could just steal a valid signature/event id pair from any other event and fool these partially verifying clients.
You're either trusting the relay to have verified everything, or not, partial validation doesn't seem useful at all.
clients are running javascript
go talk to the manager of modern software development and report a performance problem
i mean, seriously, you want javascript code to recompose a data structure, emit the new text format, hash it, and THEN also validate a signature?
the language barely even has a notion of byte arrays!
ask nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr about his tale of misery involving javascript secp256k1 schnorr (BIP-340) signature verification
it's heavy work
verifying the hash would be cheaper, and a deep compare over several relays would be faster
i don't hate web browsers and javascript for nothing
it's like writing software in 2010 for commodore 64
the reason why the usual json format of #nostr events includes the hash is so they are friendly to databases, that's it, and all
the actual client side verification of events is nasty... and interfacing performant hash and EC code to javascript is extremely clunky
I'm only saying that validation depends on validating the event id AND the signature. Only doing half validation is exactly as secure as doing neither.
But regardless, I think validation is mandatory at any performance penalty.
nostrudel now does this if you enable it, i suspect that many other clients don't, at all
you want to try and change the way protocols are implemented, have fun staying frustrated