Why have we skipped leveraging Nostr itself, to facilitate private payments?

nostr:nevent1qvzqqqqqqypzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ceqyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhkwun9v4h8xmm4dsh8xurpvdjj7qpqq228jtlx0h4qjdjzpg3dmzl5sscqsgfv30ggpyclayhwxec6syhqr54pjf

Reply to this note

Please Login to reply.

Discussion

An extremely good question! 🔥🎯

As soon as you read that, you're thinking...

Yeah. Why didn't we do that? 🤔

BECAUSE NOBODY WAS GETTING PAID TO DO THAT.

We have ubiquitous addresses and encryption and tor and etc. and y'all be like...

WE NEED E-CASH.

Payment preferences are an aspect that hasn't been fully addressed in the current specification. The only payment fields described are in NIP-57 and they are lud16 and lud06, which are suitable for zaps but quite limited in scope. Users should have the ability to set different payment options for various methods such as on-chain, BOLT12, or any others. It would also be convenient to express payment preferences for specific use cases. For example, for zaps, users could choose between NIP-57 zaps, NIP-61 nutzaps, or alternative methods like BOLT12. For e-commerce, they might prefer on-chain transactions, a different BOLT12 offer, or any other method.

We were drafting a similar concept for the NIP-99 extension for e-commerce. In this draft, we proposed including a field in the kind 0 event called `payment_preference` where users/merchants can define how they want to receive payments.

https://github.com/nostr-protocol/nips/pull/1812

Garnet and mostard use this, but they only allow adding and removing the monero field.

Using this you could add any form of payment you want and clients could list it on your profile