How to distinguish a Lightning address from email addresses?

[Bosch-0]

As Lightning addresses are identical to email addresses, how would we go about distinguishing them from emails? This concern came up here BitcoinDesign/Guide#581 (comment).

Two possible solutions mentioned:

• We could guide applications setting up Lightning Address servers that they should be presented with a pay sub-domain format like [email protected]?
• For sharing Lightning addresses we could create a URI format, something like pay:[email protected] to distinguish it from emails which use emailto:[email protected].

[andrerfneves]

There have been discussions around getting a payto: convention going but we'd need to convince browsers to adopt it over time. Uphill battle, but definitely possible. The immediate approach would be to perform the initial HTTP GET call to that Lightning Address to then check if that address even resolves to a LUD 06 payload response. If it either fails, 404s, or returns another data piece, you can rest assured it's not a Lightning Address. Does that make sense?

[markjr]

The more I dig into LN addresses the more I think the way to assert where and what these identifiers are is via DNS (I'll admit to being a DNS guy, so "hammer -> nail" may apply).

But using a well known location assumes the json file lives on the hostname of the @domain.com portion of the label, but people may want to store the payload elsewhere (tangentially, unless I'm missing something, if there is a web vulnerability where the ln address json file is stored, say, in the CMS of the webserver, then an antagonist can overwrite the destination with their own).

In this issue's case, if the data was stored in a TXT record (see Issue #43 ) then you could answer the email vs ln pay URI by testing for the existence of a TXT record, for example.

Going forward, we'll see more DNS metadata move on-chain (or elsewhere), we'll still want the ability to have a level of abstraction between the identifier ([email protected]) and what and were the payment specifier is.

(FWIW, I've been thinking about this for a long time, since before Lightning existed, but dropped it when a core dev of the era told me it was stupid. I'm thinking about it again now after a couple conversations with people I met at #Bitcoin2022 in Miami a couple weeks ago).

[marcbarbosa]

@andrerfneves do you have any thoughts on this proposal from @markjr? A TXT record pointing to a bridge server or directly to a LNURL-pay server seems a good way to move forward.
Is there a discussion around this topic somewhere else already?

[NickRHill]

Thinking out loud here;
The typical internet model is for a domain name to point to an (or series) of IP address(es) where services are delivered, port numbers which define the type of service, and within that service on that port number, the individual user. There is a characteristic nesting of services.

With DNS, we have CNAME where the service can be overlayed onto a different domain, but that service is for all users, not a subset. To stick with the normal internet model, what you are referring to is perhaps closer to a CNAME alias.

For a DNS-based aliasing system to work, the target service would need to 'know' the domain name which it is providing service for. Since http 1.1, web browsers have delivered the name of the domain in their payload so that the servier is able to properly handle the request. This allows many web sites to be served from one IP address. That is at the HTTP level of abstraction. The API is at a level of abstraction higher than that and should be independent of the HTTP implementation used to deliver the API payload.

The DNS model we have today does allow publication of capabilities and short-data domain-wide configuration. The effects of "poisoning" the DNS system is mitigated with SSL certificates for HTTPS requests. Relying on DNS entries, which can potentially be "poisoned" could therefore be less safe than delivering payment configuration over HTTPS or Tor.

If DNS could be determined as "safe enough", or if some form of signing made it safe, the resolver would need to incorporate the original domain name as well as the user name in a request to a different server. This could maybe be implemented with something like
https://destination.com/.well-known/lnurlp_origin/origindomain.com/username

Where the original payment was sent to [email protected] and that request was forwarded to a server outside of the domain to handle the LNURL payment request.

Maybe with a TXT record:
v=LnBtcUrl https://destination.com/.well-known/lnurlp_origin http://xyzalternatehandler.onion/whatever
That record may point to the same domain, or another domain, and will define the API end point. If absent, assume the current scheme. Such a record would immediately advertise that username@domain may support receiving Bitcoin lightning payments without probing the server. An arbritrary number of alternate endpoints could be listed.

[andrerfneves]

@marcbarbosa to my knowledge this is the only place where I've seen this discussion