<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello,<br>
    <br>
    We have the <pubkey>@host format for defining a connection to
    a LN node.<br>
    <br>
    I'm wondering if it makes any sense to create DNS records that apply
    to LN nodes to serve this same information? For example:<br>
    <ul>
      <li>example.com. IN LN ln.example.com.</li>
      <ul>
        <li>Allows assigning an alternate host name for the ln node for
          a domain, like an mail server has an MX record<br>
        </li>
      </ul>
      <li>example.com. IN TXT "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw"</li>
      <ul>
        <li>Allows storing the pubkey for the LN node in a DNS record<br>
        </li>
      </ul>
    </ul>
    <br>
    If one didn't know the LN node for example.com, they could query the
    LN and TXT records and then find the information and make a
    connection using the familiar
    <a class="moz-txt-link-abbreviated" href="mailto:ybRK9h6OYmB3I4VroZBQogIadciFTw@ln.example.com">ybRK9h6OYmB3I4VroZBQogIadciFTw@ln.example.com</a> format. This may be of
    interest because if someone wants to open a channel in advance to a
    company's LN node because they know they will be receiving an
    invoice from them in the future, and they want open a channel
    directly in order to ensure a good route (and they want the channel
    to be fully confirmed/opened by the time they receive the invoice).
    This could be particularly useful when dealing with machines in the
    physical world where you want an easy way to make a connection and
    channel to with a human readable string that is printed on the
    machine, but don't even want to deal with QR codes or NFC (for
    example, your desktop computer likely doesn't have either of those
    capabilities).<br>
    <br>
    Right now, the host names associated with LN nodes that are found
    using the peer to peer gossip are more on the honor system as I
    understand it. If these records existed, one could also validate the
    information found using the peer to peer gossip protocol.<br>
    <br>
    I do realize that the DNS root servers are governed by a centralized
    entity, so this approach has it's flaws, but we could consider it
    sort of complimentary to the peer to peer gossip protocol. DNS does
    have a nice scaling property in that it is hierarchically
    distributed, so it may be more efficient long term than every user
    having a full view of the LN via the gossip protocol in order to
    find the information needed, especially when we can replace the DNS
    root servers with something that is under decentralized control.<br>
    <br>
    lnurl-rfc seems to be doing a good job at creating workflows for
    payers and payees. However, I'm not sure if a definition like I've
    suggested above fits better in lnurl-rfc or as part of a BOLT.<br>
    <br>
    <br>
    Let me know of your thoughts,<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andy Schroder</pre>
  </body>
</html>