This is just an idea, kinda thinking out loud for the moment...
Similar to the initial transition of web1 to web2 where people started using components of one site into the other creating mashup websites, and eventually APIs ended up being developed, I'm wondering if it's possible to connect lightning websites.
For example, you can use your SN wallet to pay for a lightning invoice in another lightning website. But at the moment this has to be done manually. You copy the invoice from the other website, and paste it here as a withdrawal. It works great, but I think it might be possible to make it smoother if you somehow connect the two websites.
I'm imagining a "pipe-of-sats" kind of infrastructure, where funds flow naturally from different lightning websites, a bit like the lightning network itself but with websites instead of nodes.
And of course there are other use cases, for example doing something in another website when you receive sats here, also you could do something with authentication as you can do that with lightning as well, or other crazy things, kinda like the if-this-then-that website.
So yeah, is there anything like that in the world right now?
WebLN, lnurl all work to accomplish this.
Ideal flow would be a browser extension (or a native LN browser) where you'd automatically withdraw your balance and then pay from your balance as needed (clicking and interacting with websites)
Of course, the extension/browser would be connected to your own node so you'd be in custody of your funds the entire time.
Alby tries to do that with allowances and for withdraw you have lnurl-w balance check, Alby could poll this while you're on a website.
In summary, all tools exist to accomplish this today, just need to optimize the UX
reply
I would implore you to think in more non-custodial terms from now on.
reply
And what is wrong with having few sats in a custodial LN wallet like SN? Is not KYC,. so who cares? Custodial LN wallets that are not KYC, are just fine.
Custodial wallet for small things are useful. Don't be so obsessed with "everything non-custodial". Some aspects could NOT be done in a non-custodial wallet.
I use SN wallet EXCLUSIVELY for use inside SN, sats I received here, I use them to tip and post more. I do NOT depend on these sats in real life to be so obsessed to withdraw them or be afraid that someday I will not be able to use them anymore.
Get used to spread your sats stash in categories.
reply
I understand your sentiment, however, the problem is when we think in custodial terms as the best solution for everything.
You have less than a penny on SN (I'd assume) and that makes the most sense for any person using this website, but if any perception were to be had that paying out of your SN wallet was more coinvent than Alby, and integrates everywhere, we would have completely lost the plot. This would encourage large amounts of Bitcoin being stored on SN for website payments completely unrelated to SN and that was the nature of OPs question.
If we ever get to that point, I would in fact dare to ask what the hell the point of Bitcoin is when custodial solutions for gold exist just as well.
reply
As an example, https://satsoverflow.io asks you to pay a few sats to ask a question, that's a perfect time to use SN wallet to pay for that.
reply
OMG is custodial!! Are you nuts? The world is going to end if you use a custodial wallet.
šŸ˜‚šŸ˜‚šŸ˜‚
reply
You want your custodial wallet, take a custodial wallet: https://glintpay.com/en_us/
The Bitcoin revolution IS self custody
reply
You don't understand... You have much to learn.
reply
No I do understand, sloth is a very straightforward thing to understand.
That's the whole point.
A few sats are fine to move around the web doing their thing...
I don't care if they're custodial or not.
reply
It doesn't have to be custodial, you could also just plug your own lightning node into a website and make it work like that.
reply
And so you have answered your own question
reply
Well, in a way, but this is still experimental, and I'm wondering if there are other APIs out there, or other use cases, etc.
reply