Yeah, but if we're to obsolete likes and sort by zaps, this exploit should be solved first.
Discussion
Truly! Then again most people probably wouldn't do this, so maybe it's not that big of an issue?
Not sure I see HOW though. I understand your point, but don't really see the way forward. Wallets / wallet providers don't share user data (on purpose) so provider A cannot know for a fact that the zap/payment incoming is from the same user but from a wallet in provider B.
This is where I believe in you figuring it out... you've never let Uncle Rockstar down 😉
It’s a shame there wasn’t more discussion when the zap spec was being built out. But I’m sure we can investigate something.
Yes! 💯
Needed more discussion!
I wish everyone was coming to #[7] so discussions like this could take place.
Well, seems #[8] is already on it https://github.com/nostr-protocol/nips/pull/274
Clients could enforce that users need to set their pubkey when creating a Lightning address that should support nip57. Then providers could check for a matching p-Tag
I don't see how it could be solved without introducing deanonymization / KYC; a new npub could be generated for the spoofing, after all.