> which defeats the point of lnaddress - a simple human-readable name to pay to

I don't think it defeats the point if the sender's device automatically validates that information for them

Zeus Wallet, for example, implements the protocol extensions I made for zaplocker and sender's don't see anything exceptional other than just paying a regular-looking lightning address

Their wallet automatically checks signatures and stuff in the background & sends out a public attestation as to the amount being sent and the invoice being used, thus allowing both the sender and the recipient to acquire confidence that the money is really going to its intended recipient...though I must confess that my implementation does not go all the way with this, and there are still circumstances where the server can steal money from the sender without the would-be recipient knowing it

I still think it's *possible* to eliminate this trust issue entirely but only if all lightning wallets refused to send money anywhere without validating a bunch of stuff...probably a whole new, incompatible protocol is needed because if it's designed in a way that's backward compatible with the current protocol, you can't be sure everyone's adopted the new verification stuff

> You can run the server yourself, then it is self custodial

That's fair, and, indeed, I should have chosen my words more carefully. Maybe I should have said "lnurl, by definition, if you are not running the server yourself (which ~no one does) cannot be non-custodial".

> Senders can also validate the signature in the intended recipient's invoice to ensure it hasn't been swapped (I implemented something pretty similar to this for zaplocker, though I didn't go all the way) -- that also makes it self custodial

Except, not only does no one do this, but it requires a spec extension for senders to (a) have any idea what the intended public key is and (b) requires some signaling to know whether the sender should be validating (possible using TOFU). In both cases, you need some kind of external signaling (because you can't simply trust the lnurl server, that would defeat the point), which defeats the point of lnaddress - a simple human-readable name to pay to.

bluematt

> lnurl, by definition, cannot be non-custodial

It can

You can run the server yourself, then it is self custodial

Senders can also validate the signature in the intended recipient's invoice to ensure it hasn't been swapped (I implemented something pretty similar to this for zaplocker, though I didn't go all the way) -- that also makes it self custodial

supertestnet

lightning

Hermes: A Noncustodial Lightning Address Messenger w/Fedimint

isolabellart

Not only is that true, but even if you fully trust the federation its still a useless distinction - lnurl, by definition, cannot be non-custodial. Its a single (HTTPS) server that can steal any and all payments to you. They can't take money after you have it, but its not a very interesting distinction IMO.