why should nostr clients check the description hash of the bolt11 in the zap?
What does this prevent/allow?
I am asking because we dropped the description hash in the lnurl.
And some ln implementations have issues with the description hash.
cc nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg
Amethyst, Primal, Coracle, do not do this validation. I think Snort does CC nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49
No it doesn't, I removed it when nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg requested
In my view, yhey shouldn't because it's larping. We have https for a reason.
It introduces almost no safety but at the same time a lot of incompatibility.
The main purpose is intent. Without it the zapper can make it all up. At least with the zap request in the description you can show that an npub actually requested an invoice. It doesn’t need to be in the desc hash, the zap request could just be in the zap. Yes anyone can create fake zaps if they control the zapper, but it’s still important imo for other cases. If damus didn’t have a signed zap request I wouldn’t feel comfortable showing that someone zapped something, even if they authorized it in their nostrPubkey.
one issue is that this usage of the description hash is not the intended usage by the bolt11 spec and by the node implementations. (LDK, CLN, Phoenix) (e.g a phoenix or LDK backed zap receiver can not work because of that)
Then I feel like this is also a very indirect and complicated check (decoding the bolt11, getting the hash, hashing the request,…) and it seems like damus is the only client doing this.
can we make this independent of the bolt11 somehow?
Wait, why is it not the intended usage? It works fine on my cln node. Huh? Are you referring to paying a deschash invoice without providing the description (zap request)?
