naruto on Nostr: Here's a simple design for Monero zaps. Unfortunately the NIPs process and nostr spec ...

Here's a simple design for Monero zaps. Unfortunately the NIPs process and nostr spec is pretty strongly gatekept by the current Bitcoin maxi class. That's why payment targets took a year to make it into the spec. Not exactly an encouraging environment for people interested in anything but Bitcoin to contribute to the spec.

quoting
nevent1q…fa6z

I figured this was the idea. That is definitely possible to do.

The unfortunate issue is it's trivial to see which users have received encrypted blobs with nostr to my understanding. So it's inevitably going to be trivial to correlate Monero transactions to nostr users using the feature.

Also if you query the node for the transaction to verify it's a valid transaction, then you tell the node which transactions are yours.

Monero wallets try to avoid leaking that info.

For something like zaps, I don't think that kind of design is such an issue. But as a general wallet, it's arguably not ideal. It's better than wallets like Edge that reveal all user's plaintext transactions to Edge though.

Also, I reviewed the zaps NIP and I see the interesting tidbit it does is have recipients publish the zap event via their lightning daemons. That way senders aren't the trusted ones to update the zap count on recipient's notes, recipients aka note authors are.

This could easily be designed for on chain payments across any other asset including Bitcoin or Monero with a similar idea: sender sends payment + info in a blob to the recipient, only sender updates local state of the zap counter, and once recipient opens their client the client confirms the payment and send the "zap receipt"-equivalent event to relays which updates the zap counter global state.

Idk if there have been other server-side expectations for other nostr features, like zaps expect from lightning nodes, but the protocol could easily be extended to have servers basically do the same thing for other assets too (sender sends payment info to user's configured server, server validates receipt and publishes receipt event).