64 sats \ 5 replies \ @k00b OP 29 Apr \ parent \ on: SN's wallet plans meta
We'll wrap the receiver's invoice in a hold invoice that pays us our fee, but we only get paid if the receiver gets paid. This also has a side effect of hiding the receiver's node pubkey from the sender. So, we get our fee, it's non-custodial, and the receiver's privacy is perfect.
Be very careful with this. Study the LNProxy source code and understand why they make the decisions they make. Also understand that this may result in more force closes from the payer side. It's easy to lose money on this if you're not careful.
One thing you don't have control over is what CLTV is being set on the receiver invoice. If you don't have a direct route to every wallet, which you might be able to do easily enough, you're also going to get into fee and timeout trouble.
You mention zeus somewhere else, a hodl invoice to a hodl invoice just sounds like a disaster.
You're going through all of this "fee credit" work, might as well make fee credits a requirement throughout this site. It sounds like as a non-custodial receipient, I'm still going to be acquiring "fee credits" from non-wallet users, and I'm effectively unable to do a single thing with those besides upvote with them. Perhaps just treat fee credits as a requirement to participate in the site at all, make it required gas in order to get credit for zaps to other people.
2nd point
You're recreating the wheel here a lot. If you look at what's been done with nwc.dev, you can effectively just create two invoices, one to the recipient's wallet and one to you. Send them to the wallet via NWC and have them both be paid by the sender. You can use lnurl verify to ensure they are paid, and if both of them are not, then don't show the upzap at all. Granted, there's not a lot of wallets that support NWC yet.
All of this is going to be difficult, sucks to see you have to do this. I would rather just deposit sats from my wallet and occasionally use this site for the few dollars worth of sats that are involved for most people. Though without the ability to withdraw those, it starts to make this site less worth it for me. Nostr has already figured this out, you're just in the difficult position that you have to monetize through the use of zap volume. The other nostr clients aren't doing this.
reply
Thanks for the thoughtful reply.
If you look at what's been done with nwc.dev, you can effectively just create two invoices, one to the recipient's wallet and one to you.
We can do 2 invoices, but for a QR-code payment it's an undesirable UX. Also lnurl-verify doesn't look like it will be merged, nor can we rely on everyone using lnurl for receives.
Nostr has already figured this out
š¤
you're just in the difficult position that you have to monetize through the use of zap volume.
We don't monetize with zaps. We take a fee for sybil resistance and pay it back out in rewards.
reply
Don't let perfect be the enemy of good. Sybils are great and all, but you'll find that this already works pretty well.
reply
We'll wrap the receiver's invoice in a hold invoice that pays us our fee
That is a RED ALERT: IMMINENT FORCE CLOSE channel
We will see so many noobs with these:
@remindme 6 months
reply
Anything in the SN setup that @k00b proposed that is different from the general info in your various guides? In other words: is the proposed SN use case / architecture special somehow, or would someone reading a subset of your guides be well-positioned to interact with SN in the new era?
reply