Thoughts on Lightning Address

I think it’s undeniable at this point that the creation of Lightning Address has made the usage of custodial Lightning solutions increase – or at least be more prominent. We see these stats everywhere of how many of Nostr Lightning Addresses are custodial, and how services like Nodeless and Geyser only work if you give them a Lightning Address, and that probably sounds like a lament to many people who thought Lightning would be this amazing network of self-hosted nodes that everybody runs, and is indeed sad.

Well, on the other hand the Lightning Address flow is clearly an improvement – to most people – over the cumbersome invoice flow. Since the early days of Lightning people had been complaining about the fact that there is no way to “just send money to an address”. Even though I personally liked the invoice flow much more (especially if they had structured, signatures, clear descriptions and amounts, payment proofs and so on) the fact is that most people didn’t and slowly invoices were losing their meaning entirely anyway.

This improvement in the payment flow, along with the open, easy and interoperable way that Lightning Addresses work, has opened space for new use cases that maybe wouldn’t have existed otherwise – like the services mentioned above, and others. So we can’t really say this was all a bad thing.

We also shouldn’t say it was a bad thing to have Lightning Addresses being invented at all, because if they hadn’t been invented like they were, there is a high probably they would have been invented in other forms, probably much worse, that would involve private deals and proprietary integrations with ad-hoc APIs, SDKs and JavaScript widget buttons with iframes. I even remember some of these things starting to happen at the time Lightning Address was created, and we have more evidence of these things even after Lightning Address, like some “partnerships” here and there and the “UMA” protocol. So maybe Lightning Address was just the best possible protocol at the best time, and all its problems are not really its problems, but symptons of the problems of the Lightning Network (or maybe you wouldn’t call these “problems”, just natural properties, but doesn’t matter).

The saddest realization of all this process, for me, was that Lightning payments are mostly used for tipping and not for commerce as I thought they would in the beginning (hence my love for the invoice flow). Specifically, LNURL-pay and its cool hidden features that went mostly unsupported, were all designed with the goal of enabling new use cases for commerce in the real life, outside the web, and Lightning Addresses would have tied nicely into that vision too – but that was all definitely an irredeemable failure.

I thought I had more things to say about this, but either I didn’t or I forgot. The end.