pull down to refresh
Re:But if the client uses cache-after-verifyCache 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 theid
from the event payload each time you load it; do not rely solely on a relay-supplied or previously cachedid
. 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.
sig
on the kind1059
(and thep
tag), if no match against the givenpubkey
then discard because it's spoofed.content
of the kind1059
, this results in a json string of a kind13
and not an url.pubkey
to be a known sender and then thesig
on the decrypted kind13
message to match that key, if no match then then discard 1 - you now have authenticated the entire message includingpubkey
andcontent
to be from a known contact.n
(often kind14
) from the previously decrypted kind13
, which isn't signed, but that's ok because we've authenticated the seal.Footnotes