Just dropped a draft LUD on the LNURL repo for verification of hosted Lightning addresses. Feedback appreciated.
Discussion
Fantastic idea. I really love using Zeus and with the hosted Lightning address support, I can use my own node and don’t have to use custodial services like Wallet of Satoshi.
We might have to launch our own service to support our frens who run their own nodes at home but don't want to run a web server 🤔
Could Nostr be used for communication instead of needing web servers?
100% - Kukks has a proposal here: https://github.com/lnurl/luds/pull/203
Still needs a server to reply to them though (but not a publicly accessible web server). If people delegate that to others, this proposal is still quite helpful.
Did you say "hosted" LN wallets?
#[0] had some feedback on that choice of words 1y ago: https://dergigi.com/2022/06/27/the-words-we-use-in-bitcoin/
Seems like his beef was moreso with "unhosted"
Yes.
When it first came out, "hosted" was strategically chosen to gaslight node-runners and newbies into down-playing the importance of self-custody.
The technical side of your spec may well solve a technical problem, but the title helps propagate a concept that's antithetical (through the ensuing discussions, changelogs, feature names, UI labels, review podcasts mentioning it, etc).
All I'm saying is creating a spec with "hosted" in its title is IMO self-defeating, if not even damaging long-term.
"Un-hosted" implies "hosted", both have the same effect on framing the discussion.
What adjective would you use for a LN address provided by one of these services then?
It’s not easy to find another adjective, “Centralized” comes to mind but that may sound negative, though it’s as accurate as hosted.
“Mediated” is more ambiguous.
I’ve never heard of “Betwixt” before; between (two people or things).
"Custodial" is the most neutral that comes to mind.
It tells you the wallet and the funds are essentially owned by someone else.
Seems to be the main point of adding the extra adjective in the first place. Otherwise you'd just say "wallet" or "LN address", done.
in this case though we need a distinction between services that custody users funds entirely and those that provide a lightning address that resolve to a user's own wallet/node back home
> somewhere in the middle are services that run the web server for people who run their nodes at home behind their routers
LN Address Bridges?
So the concern here is the node behind the ln address may be replaced deceptively?
Perhaps a better option is clients' checking ln address against a cache of node public address. And warn the user if there seems to be a change. Change might be an innocent technical necessity or a deceptive one the users may decide themselves.
Where's that cache live? How's it maintained? How does one update it? And how do you determine if that is a 'deceptive' change or not?
Seems much more complicated imo
It may live in senders client. Compromise is first transaction will not have a cached value. It will be there for the following ones.
The readability caveat seems like a big one to me. Maybe there's a way to represent the pubKey hash in a more human-readable way (with BIP39 words for example). Also I'm not sure I see a way to use the introduction point instead of the receiving node in the context of path blinding, because a deceitful web server could still use the same introduction point in its own routes - I'd actually be telling them which one to use in my Lightning Address.
I think you're right RE blinded paths
i think a better solution i just to take out the web server all together? https://github.com/lnurl/luds/pull/203
All while he was catching rays.