0 sats \ 5 replies \ @supertestnet 17 Jan \ parent \ on: Hermes: A Noncustodial Lightning Address Messenger w/Fedimint lightning
Oh I see what you mean now. I think you are saying Hermes is non-custodial because they don't have your btc, fedimint does. Is that right?
If so, that doesn't make it non-custodial. Imagine if instead of using fedimint Hermes showed you a "deposit address" to coinbase. And then they said "You see, we are non-custodial because we don't have your btc, coinbase does."
If you tell users "non-custodial" when it's really all a frontend for a custodian's api, you're lying. Tell users the truth so that they are informed. They may be willing to trust that person or group with their money, but the wallet should definitely not lie about the trust model by calling itself non-custodial.
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.
reply
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
reply
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