A good rule of thumb is DON’T BREAK USER SPACE.
This is something Linus Torvalds constantly repeats regarding the Linux kernel development.
LNURL is perfect just the way it is
Yes indeed, in the context of nostr, Lightning Address is merely used as a common API endpoint.
Like people could just use lud06 metadata and input https://domain.com/.well-known/lnurlp/user instead.
But Lightning Address and its use-cases long predates nostr.
BOLT12 does not remove the requirement to be online in order to pay.
I think nostr users will keep using custodial LN wallets.
So whether BOLT12 or Lightning Address is used doesn’t matter that much actually.
Those who run their own LN node could use BOLT12, but that’s a minority.
⚡️ hampus@blixtwallet.com
This Lightning Address is special.
When you pay to it, my Lightning Box solution will forward the request to the phone, where Blixt Wallet respond with an invoice.
This is the first time a self-custodial LN wallet supports Lightning Address.
This is part of my on-going work to support receiving via Lightning Address for mobile self-custodial wallets.
https://github.com/hsjoberg/lightning-box
Android supports foreground services, meaning that Blixt Wallet can stay online all the time to answer incoming requests (no effect on battery).
Though the normal mode of operation for Lightning Box is that it'll take the payment on behalf of the user and then next time the user opens wallet, it will auto-withdraw from the Box, thanks to LNURL-withdraw.
But if the wallet is online already, it can just forward the request.
LNURL-pay was first developed for commerce/B2C.
Years later Lightning Address came along and became a success, because it allowed for an easy to write & read handle.
Soon even custodial wallets started using Lightning Address and this later lead to widespread usage on nostr.
It's a succession of events that lead to the current situation.
So as it stands now, non-custodial LN wallets are losing on walkover to custodial wallets, where you have easy access to a Lightning Address.
My Lightning Box solution tries its best to work within this framework that has been developed and gives a sound alternative to using a 100% custodial and trusted Lightning Address solution.
#[0]
Other technologies such as BOLT12, especially with "async payments", could help steer people away from Lightning address.
But it cannot fully replace it, because the primary value proposition of Lightning Address is an easy to read and write handle, which BOLT12 doesn't have.
It's possible we can do some neat "spacechain DNS with BOLT12/BOLT11 AMP" and whatnot, so I'm open to possible ideas.
That’s not really a fix considering relays also have to ban sanctioned IPs
Definitely exciting stuff.
It will take some more time before we’re ready roll it out.
Gotta evaluate the feasibility and develop a registration system for this.
But when it’s done I hope people can start using this instead of custodial solutions!
Yes, an invoice is literally created inside my Blixt Wallet app and then gets paid.
Check this out:
Indeed!
Should’ve hello worlded even earlier though, since I’ve known about nostr since the absolute start. 😅 Too busy with Blixt.
Better later than never though.
I should’ve been clear that this is not publicly released yet. My apologies.
But yes I agree with your message. When this is out, you shouldn’t need to use custodial Lightning Address solutions anymore.
In fact, this complaint of custodial LN being on nostr was partly the reason why I started looking into my Lightning Box service again.
Sorry, the text was copied verbatim from my Twitter thread where I didn’t have space to properly explain within the tweet contraints.
This is the first time a mobile LN node wallet (like Blixt Wallet, OBW, Breez, Phoenix etc) supports this.
Alby does this, but it requires a separate normal Lightning node running, which increases the barrier to entry drastically.
Yes, Blixt should run just fine in Android emulation.
Linux port is WIP.
Haha yeah we have some harsh ban waves because of the amount of bots.
Please tell me your handle here or in DMs and I’ll unban you.
Thank you! Yes, I do the trade-offs being made are sound.
Not next version, but soonish. Are you in in our Telegram group @BlixtWallet?
I will start an internal alpha eventually with people that are interested to try it out.
⚡️ hampus@blixtwallet.com
This Lightning Address is special.
When you pay to it, my Lightning Box solution will forward the request to the phone, where Blixt Wallet respond with an invoice.
This is the first time a self-custodial LN wallet supports Lightning Address.
This is part of my on-going work to support receiving via Lightning Address for mobile self-custodial wallets.
https://github.com/hsjoberg/lightning-box
Android supports foreground services, meaning that Blixt Wallet can stay online all the time to answer incoming requests (no effect on battery).
Though the normal mode of operation for Lightning Box is that it'll take the payment on behalf of the user and then next time the user opens wallet, it will auto-withdraw from the Box, thanks to LNURL-withdraw.
But if the wallet is online already, it can just forward the request.
True. I see many people thinking that BOLT12 will make LNURL-pay obsolete. But they serve different purposes.
(Also, I wish BOLT11 AMP would get implemented across the board.)
So true
I don’t think so, no
Yeah it would require new output type segwitv2 and using Taproot/Schnorr.
So if we decrease or disable the discount, it wouldn't have such advantage.
But real financial transactions would have a benefit as you can easily consume outputs.
note15jg44uev8y8fmal0xaxty23ks4mxlav75ae2xwtmv42gkm9py3lsazd6rf