0 sats \ 2 replies \ @supertestnet 19 Jan \ parent \ on: Hermes: A Noncustodial Lightning Address Messenger w/Fedimint lightning
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
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.
reply
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
reply