This is dope. Congrats! I hope to see some services such as @silent_link, tunnelsats etc adopt this.
reply
Oh, no way! I was designing something super similar, completely independently! Didn't even know NIP-47 existed, let alone was getting traction!
I was working on a less resource intensive, more private-by-default, technique in my design philosophy.
Not sure if it's competing or complimentary to the approach you have here. Maybe the world needs both.
If I understand NWC, and the "billing address" analogy, then the billing address would then need to be "managed" by the user (and to maximize privacy, one would need to make one per vendor?) and then track it all by the merchant. Then, there would always be a risk that the list of these "billing addresses" would be leaked, and joined, exposing the users buying patterns.
If the NIP-47 design is a "one-to-one-to-one" solution (where merchants map invoices map to user's payments), then my philosophy was a many-to-one solution. Where users would pay a specific amount to the merchant, along with a DM containing proof that they paid that specific numbered invoice.
So, a merchant would have say a weekly subscription service, that users have to pay every week. The merchant would announce to the world "Hey, everybody that wants my service, send me a DM that proves you send a payment to pay for this invoice".
The user would basically create their own receipt, proving that they paid for this week's service.
Admittedly, this only works for fixed-price re-occuring bills. And, the merchant would have basically a sku-like idea to their billing. There would be a cron job running for each billing cycle, for each subscription-sku.
reply
NWC is more of a way to deliver invoices to a user's wallet, rather than prove you paid a merchant. It works great for subscriptions because you can send directly to the user without the user having to remember to pay the merchant.
reply
Right! And I love it. I understand that it would work great. But I'm just saying there are privacy trade-offs. With NWC, a relay is incentivized to figure out all the billing addresses for one user, and then sell that list. The relay will basically have a honey-pot of a user's spending patterns. Assuming I understand the protocol correctly. Which, tbh, I haven't read it fully yet.
To simplify, NWC, has address-re-use privacy concerns, that could be reverse-engineered by a slightly ambitious relay. Have I got this part correct?
reply
No, relays can't interfere. These are encrypted requests.
reply
So the relays don't see a public key for the "billing address"?
reply
They just see encrypted DM's, that could be for any reason. But also, NWC dictates that a specific private/public keypair is used to communicate with the recipient. So even if they know a DM is meant for NWC (they wouldn't know), they couldn't do anything with it.
reply
Gotcha. I guess the relay would have to make more assumptions than I presumed, to get even crumbs of intelligence. Thanks for the taking her with me, Tony. Keep up the great work you guys are doing!
reply
Excited to see how this could be used for more p2p subscriptions but also how more services can interact with it too.
For instance, SN can be configured to have user actions come directly from the user's self custodial wallet. Budgets can be set or the wallet can be configured to manually approve the payments. SN asks for one NWC string once and it can send the nostr DM with an invoice every time the user upvotes.
That way only SN rewards are in SN's control until the user withdrawals, otherwise zaps are sent from the user's wallet.
reply
Thinking about renewing my subscription so I can do Munity gifts but my subscription fee is stuck on chain it seems
reply
As in it is stuck in pending or that a channel closed and all of your balance went back on chain?
reply
Back on chain
reply