zaps still have too many moving parts which makes it confusing for users.
how can we optimize this?
zaps still have too many moving parts which makes it confusing for users.
how can we optimize this?
This helps a little
Here’s the index of them, and the GitHub
https://jim-index.albylabs.com
https://github.com/getAlby/jim
nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm
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.