Trying to understand where the zap counts and zap lists in Nostr clients come from.
Maybe it works roughly like this.
A user associates a lightning address with their pubkey in their profile. Others then send zaps to that lightning address, using an LNURL server and a mechanism by which they specify the intended recipient pubkey (i.e. presumably the pubkey in whose profile the lightning address was found). They can also specify a Nostr event ID alongside their payment, to indicate what event the recipient pubkey is being tipped for. The LNURL server broadcasts 9735 receipts to relays which are signed by the server. These receipts contains among other things the sender pubkey, the recipient pubkey, and any Nostr event ID that was specified by the sender. The LNURL server is trusted to provide correct information.
Nostr clients then collect whatever 9735 receipts they can find that refer to a given Nostr event, count up the known zaps, and generate lists of sender pubkeys that are displayed underneath the event. Nostr clients can also count up the total known zaps received by a given pubkey.
Other than the signature on a user's profile, there does not seem to be any cryptographic relation between that user's pubkey and the lightning address to which zaps intended for that user are sent, right? I.e. there is no cryptogrphic guarantee that the specified lightning address is correct or current for the profile pubkey. If a user were to change their lightning address in their profile, would clients attribute payments made to both lightning addresses to that user's pubkey and add them up - it seems maybe yes?
Also, it seems that NIP-57 allows 9735 receipts to specify a recipient pubkey and a Nostr event even if the recipient pubkey is not the actual signer of the Nostr event. So you could zap pubkeys for Nostr events that are not signed by these pubkeys. That actually seems desirable, but do clients have a protocol for how such zaps are attributed?