zaps are easily the ugliest part of nostr. They're just absolutely so painful to work with
Discussion
What if...
We stopped using them 👀
No way, the UX is awesome, I'm just griping about the spec
?????
Would be interested in hearing your reasons as to why.
- Multiple formats (lud06/lud16) in the same fields (often the wrong one)
- Poor CORS support means you have to proxy address fetching, adding another point of failure
- You have to fetch, cache, and handle missing data for a user's kind 0 and address metadata
- A mixture of url parameters, json and bech32 make things exceptionally ugly
- Zap servers often don't give you good error responses
- Zap splits use positional, optional arguments. Omitting weight for some zap splits and not others is considered ok
- The mixture of msats and sats might mean you send 1000x or 1/1000th as much as you intended
- Wavlake uses a non-standard zap tag which doesn't include pubkey or hint
- There are lots of ways to collect an invoice: NWC, nip 07, copy/paste invoice
Just off the top of my head
Sounds like a more robust and standardizing NIP is needed to either rebuild and improve zaps or a completely different method to achieve the same basic feature.
Can you clarify for me, is a zap the sending of Bitcoin via Lightning, or is it a message that accompanies the Bitcoin sent over nostr?
It's the nostr part, in theory zaps could wrap any payment method
Ya and the worst part is you can't even use em as a payment mechanism. Like say you made a post that said, "here's the invoice for this T-shirt and as soon as it gets paid by anyone for any amount, it is purchased for me thanks for the tshirt everyone!!". But ya, zaps can't confirm a txn, only your wallet/lnbits api can do that..
Let's fix with a zap 2.0 spec?
🫂
Here have a #zap to dry your tears :-P