Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-12 📝 Original message: Hello, We have the ...
📅 Original date posted:2021-09-12
📝 Original message:
Hello,
We have the <pubkey>@host format for defining a connection to a LN node.
I'm wondering if it makes any sense to create DNS records that apply to
LN nodes to serve this same information? For example:
* example.com. IN LN ln.example.com.
o Allows assigning an alternate host name for the ln node for a
domain, like an mail server has an MX record
* example.com. IN TXT "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw"
o Allows storing the pubkey for the LN node in a DNS record
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 ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com 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).
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.
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.
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.
Let me know of your thoughts,
--
Andy Schroder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210912/14a13a88/attachment.html>;
📝 Original message:
Hello,
We have the <pubkey>@host format for defining a connection to a LN node.
I'm wondering if it makes any sense to create DNS records that apply to
LN nodes to serve this same information? For example:
* example.com. IN LN ln.example.com.
o Allows assigning an alternate host name for the ln node for a
domain, like an mail server has an MX record
* example.com. IN TXT "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw"
o Allows storing the pubkey for the LN node in a DNS record
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 ybRK9h6OYmB3I4VroZBQogIadciFTw at ln.example.com 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).
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.
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.
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.
Let me know of your thoughts,
--
Andy Schroder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210912/14a13a88/attachment.html>;