I would deploy it but the sticking point right now is how to associate a mining channel with a payment request. Can it fit into the name field? I don't want to add an account system. If we had a static cashu payment field for each npub that might work.
With the current architecture each payment request would require a proxy pool deployment. Not the best UX.
I could solve it with an Sv2 protocol extension but I would prefer a dumber and easier solution.
Login to reply
Replies (1)
Cashu payment requests sounds interesting!
Associating a miner with a Nostr npub, and that with a payment request is an additional indirection step (extra complexity), but it has several advantages: access to user profile, user-option to choose cashu-vs-lightning payout, option to create zap/nutzap events, option to message users, etc.
If you feel this info belongs to Nostr user profile, put it there in a proprietary field and start using it (propose standardization). Or another way is to use the Arbitrary custom data Nostr standard store this use-case specific info -- I think this is more appropriate in this case, since the payment request is use-case specific. Either way, you have to take care of setting this (contrary to e.g. lightning address, which can be set by any client).
I plan to use Arbitrary custom data for user settings like payout frequency (less often than default), payout threshold (higher than default), or payout method (zap vs. plain lightning pay vs. nutsack wallet vs. nutzap).