I think the main cause of this is the hash being included in the message. That's the design error that puts bad ideas into people's heads.

I guess they kind of address it but probably the best thing would be to delete it from the message altogether.

optimism

Cache what? That any message from a pubkey no longer needs to be verified? What's this feature?

It's a vulnerable performance optimization. See Q4 in FAQ above:

When caching events, first verify them successfully 

 from the event payload each time you load it

; do not rely solely on a relay-supplied or previously cached 

. Vulnerable clients followed the “cache-after-verify” rule but still failed integrity checks because they cached only the id and skipped this re-computation step.

nostr

Not in The Prophecies: Practical Attacks on Nostr

> Re:
>
>> But if the client uses cache-after-verify
>
> Cache what? That any message from a pubkey no longer needs to be verified? What's this feature?

It's a vulnerable performance optimization. See Q4 in FAQ above:

> When caching events, first verify them successfully _and_ **re-compute the `id` from the event payload each time you load it**; do not rely solely on a relay-supplied or previously cached `id`. Vulnerable clients followed the “cache-after-verify” rule but still failed integrity checks because they cached only the id and skipped this re-computation step.