And I think the fiat support in Payment Targets (CashApp, Paypal etc) is a good feature for normal non-crypto people to be attracted to nostr. That has potential to catch on later and retain more people arriving to nostr.
Expecting users to run a server (or worse, use custodial payment software) is an infinitely worse UX than having users leave the app to make a payment in my view. And I can't imagine nostr apps shipping full fledged Bitcoin/Monero/Eth wallets ever, nor ship "deposit fiat and send it to other nostr users." My view: leaving the app is ultimately the best tradeoff.
It may not have worked well initially for Bitcoin payments as it was originally implemented, but I think a flow modeled closer to zaps but generalizable for any payment can definitely succeed, at least for sure with Monero people. I drafted a spec here that I think is extremely easy to develop on both nostr side and wallet side, and could land on a nice UX:
quotingWalking through a potential on chain Bitcoin implementation:
nevent1q…2m05
1. Sender taps zap button on a recipient's note.
2. Sender's nostr client generates a bitcoin URI that also includes a flag that it's a nostr zap payemnt.
3. Sender opens the URI with a Bitcoin wallet app, which auto populates the payment fields.
4. After successful send, the Bitcoin wallet generates a nostr URI that has the transaction info filled in.
5. Sender opens that URI with a nostr client, which then sends an event containing the original note id and transaction hash and expected recipient address to a relay.
6. Relay checks the Bitcoin chain for the transaction and if valid, updates the zap counter for the note.
In step 5, the sender can be prompted to manually enter the transaction info so the Bitcoin wallet doesn't need to generate a nostr URI. But a nostr URI would be nice and simple.
Also this flow is obviously easily interchangeable with Monero or Ethereum.