Nostr Web Client

It's taking too long to ask how I should do it. I'm about just say fuck it and make a new nip after I make an implementation and we can workshop it after.

I think a new "w" tag in the kind 0 with an array that looks like

["BTC:bitcoin:

], or [XMR:monero:

[::

]

The "w" tag is an "Accepted Form of Payment"

You can have as many as you want as long as the network and asset are unique from each other.

Client can decide what to show.

Should define a few networks in the nip but it should be noted that clients can interpret the w tag however they want.

You could even deprecate ln address in the content of you did something like

w ,

BTC:lightning:

Gzuuus 10mo ago

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

Reply to this note

Please Login to reply.

Discussion

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.

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.

OceanSlim 10mo ago

Don't you think a user should have the ability to specify multiple preferred payments? As a merchant, I would still like to accept Liquid, USDT or BTC lightning for instance.

Laeserin 10mo ago

I'll take anything I can sell for Bitcoin, to be honest.

Laeserin 10mo ago

But, I'd like to be able to say "Bitcoin on-chain or Lightning self-hosted preferred" because that saves me the conversion fees.

Gzuuus 10mo ago

Absolutely. The `payment_preference` field is designed to express payment methods for "non-social" cases like zaps, tips/e-tips, where you want to specify how you prefer to receive payments for "the other stuff", services or goods you offer, in the case of a merchant. It's entirely valid to have multiple payment options, which we can implement using an array. For example:

`payment_preference: ["lightning", "manual"]`

This approach aligns well with your proposal of including wallets in tags. We can also introduce scopes, like this:

`payment_preference: ["lightning", "w:bitcoin", "w:usdt"]`

Alternatively, we could use just "w" to indicate all wallet details found in your profile as "w" tags. wdyt?

Laeserin 10mo ago

Yeah, they seem like things that could be combined.

Gzuuus 10mo ago

LG 🚀

Rand 10mo ago