pull down to refresh

  • What were some of the challenging design considerations when developing the Lightning Address standard?
  • How do you envision Lightning Addresses's changing in the future?
  1. Because it built on top of the LNURL Pay specification, there were 2 main concerns:
A - the URL path for .well-known/... B - Whether to remain true to the internet-identifier RFC and do username @ domain.com, or whether to change it to username $ domain.com (or some other identifier)
In the end the path chosen was the one that made sense at the time. Hindsight is 20 20 so there's always improvements that can be done, including the structure of the path. I do think it was the right choice to stick to the RFC of internet identifiers, though there are those that disagree as it generates confusion with email addresses. In my opinion, if we are to have a world where money is inherently part of the internet, they money will quickly become part of emails/chat protocols. And there's nothing stopping someone from having the same email address and lightning address, technically.
  1. I expect any Lightning-enabled platform to provide user's with Lightning Addresses since it's the most seamless interface for end-users. I expect more discussions about adding more payment methods under the same Lightning Address. This means a Lightning Address could be used to pay over Lightning through LNURL Pay, or onchain through a Bitcoin addr, or through Keysend given a pubkey, etc, etc. I also expect services that provide hybrid Lightning Address approaches to appear soon (basically they offer you a Lightning Address but they only hold your funds until you're back online, at which point they push the funds to you via keysend --> for example). Also fiat-fx-through-lightning-address is pretty cool.
reply