We did some zap tests on this noteā¦ we made six attempts toā”zap this note, at jimbocoin@btcpay175473.lndyn.com, over a period of 23 minutes. Six of the zaps were successfully paid... Please check for 6 satoshis received. Problem: we found that your lightning address server **did not** produce any zap receipts. This means that nobody else could see see that you got zapped... no number appears next to the ā”icon after zapping.... We recommend that you use a cloud-based Lightning node to get more reliable zaps.
Discussion
Zap receipts reveal the location of your node and are generally a really terrible idea.
Also Iām lazy and havenāt bothered to set it up
Given that zaps require a Lightning Address, do Zap Receipts add any more bad stuff? Also since Zap Receipts are sent via Nostr relays, I'm vague on how they would actually reveal your location. They can be sent by any computer, anywhere. In our case they're sent by our web application a Rizful.com, the same one that receives the http request to initiate the whole "zap" dance according to Nip-57.....
AFAIU they work through generic HTTP callbacks. Implementing a LN-Address server can create invoices without being on the same server as the node, or it can be behind a reverse proxy to hide it. You can proxy the outbound response but (a) I absolutely refuse to have a TLS client in my lightning node š¤®, (b) some websites block Tor anyway so callbacks may not be as reliable and (c) proxying through Tor is a bunch more work than just serving being a reverse proxy.
Generally the zap design is horrendous and only makes sense for custodial wallets that already run a bunch of HTTP infra. Luckily thereās a better way (just literally do a BOLT 12 payment and have the payer post the payment proof as a nostr event, rather than making the payeeās lightning node somehow nostr-aware), but need movement there.