Nostr Web Client

That's cool, and I like the design since it already establishes a way to express different payment methods apart from "native" ones like NIP-57 and NIP-60. However, there's definitely a privacy flaw for some wallets that shouldn't use static addresses, such as on-chain addresses, where reuse is not recommended.

I'm drafting something for markets and merchant payment preferences. We're using NIP-78 as a way to track xpub index. Also, for markets, we're writing a spec where we use a 'payment_preference' tag in the kind 0 event for the merchant to determine how they want to be paid for their services/products. The value of payment preferences can be lightning, cashu, or manual as an interactive/server-assisted method which is not Nostr-native

OceanSlim 10mo ago

We all know we should rotate addresses for privacy reasons by now. But users should still have the option to have as many donation addresse as they want. I should be able to tell people where they can send me money, even if it isn't the best privacy policy. Privacy is my right to selectively reveal myself. If the user wants to reveal some aspects of how people pay them, that's their choice.

The nip will define a few different assets networks and addresses but the spec will be broadly left open and up to the client to interpret them ultimately.

Not to mention people could add liquid or monero addresses or always create new wallets for donations and they can rotate the address manually whenever they like.

Reply to this note

Please Login to reply.

Discussion

Gzuuus 10mo ago

Sure, but where do we solve the case for users who do not want to reveal themselves publicly in a place where you cannot control the reach of your publications? I think the only solution for the case of btc on-chain to keep privacy is to fallback to a server to provide a fresh btc address. Do you think this can be compatible with what you are trying to do? Like `["w", "bitcoin", "https://mypayserver..."]` ?

OceanSlim 10mo ago

If you don't want to reveal yourself, then use a new wallet or don't post addresses publicly, especially addresses from a wallet that you've been using.

Gzuuus 10mo ago

I want to reveal payment methods that I accept and people can find in order to payment. Even if you use a new wallet, it's very poor privacy. I totally agree there are going to be people wanting to set a static BTC address for some reason like donations. But I also think worth to explore how to offer also pro privacy options. Rn for example if you have a ln address you have to fetch an invoice from the server, I was talking about the same pattern here, but instead of receiving a bolt11 invoice you get a BTC address

OceanSlim 10mo ago

I'm not saying the other options aren't necessary. They absolutely are. I'm just saying we should have both.

That's for sure 🤝

🤔 Interesting

Wdyt?

I had this idea, that it might be possible to generate new addresses on the fly, over Nostr relays or in the client , or something. Instead of a server. And the client would just show a different one, when called up. But I don't know enough, to know if that would work.

Gzuuus 10mo ago

Hmm, I don't think there's any other way to do it for this case that isn't supported by a server responding or updating something when required, since there's no magic way to expose something, detect usage, and expose something new next time without requiring payer interactivity. At least for the xpub case where you want to generate a new address when someone uses the previous one. I was thinking sometime ago about "payment channels" and dh, so you can set up something more or less static that "changes" but with people you previously set up that dh. I mean you could calculate all shared secrets for all your contacts and assign a different xpub to each one. But it seems quite convoluted.