zaps still have too many moving parts which makes it confusing for users.

how can we optimize this?

Reply to this note

Please Login to reply.

Discussion

ecash wallets and zaps. users get wallets that are portable across apps and can start receiving by just having a pubkey.

this actually adds another layer of complexity to the zap process.

Thought you were referring to UX

it separates concerns, which lets the discrete parts of the stack specialize

this is how every complex technology develops

yes agree, ecash fixes the lightning setup hot mess…best case is default ecash like #olas trying, then also nwc support to support other ecash wallets.

ecash adds another layer to that zap process.now you also have mints involved.

that’s just ui

have you ever tried implemented any of these things?

yes

and adding the ecash mint in the zap flow is just UI? ok...

Yes it can all be optimized. Still very early but please, lightning is either kyc garbage fest or setup nightmare

öhm... you know zaps a re lightning payments and all relevant ecash implementations have lightning under the hood.

your KYC regulations don't magically go away just because you call something cash.

and the setup is just outsourced to a mint (and some abstractions are added)

please correct me if I am wrong...

You are right. ✌️

Maybe bolt12 static addresses and npub-locked cashu tokens.

Right now Alby's self hosted hub stack works for me, but it's too big a leap for newcomers. I rarely have a zap fail with channels to WoS and Megalith unless the receiver is down, which means Alby's middleware between LND and Nostr is reliable. But I don't know how much spaghetti is making that happen.

From my limited perspective, there is one fundamental problem: how do you coordinate a payment between two nodes on the lightning network?

There are sovereign nodes and permissioned nodes. You're either trying to send a payment on your own keys or ask a sovereign to send a payment on your behalf. And the receiver is the same.

Now coming at it from the top, Nostr is a social graph among humans that lets you find people that you want to send payments to. The problem splits in two. How do people advertise their sovereign/permissioned lightning node in a way that other people can pay them reliably? And how can my Nostr client gain permission to use my node to pay an invoice it fetches from the receiver?

You mean using or setup? Assuming setup, imo best path is to make self-hosted albyhub w/ LN address simple for 'uncle jims', so that when others come around they dont have to do anything but signup. Not very sovereign but easiest.

in what sense?

clients, relays, zapper, wallets, just a lot of parts involved where things can go wrong.

ecash

Agree. Having implemented it for our custodial wallet (with additional relay integration, so our users don't miss a zap, regardless of which relays the sender uses), I must say it was hilariously complex for not even having a guarantee that the payment happened.