Open Lassulus opened 8 months ago
Indeed, this is something which has also been put forward internally. There are some practical considerations, most notably a DNS record (and hostname) can have multiple records, and we need to consider how to handle that. But I do think a basic implementation for this (for now) can be doable (probably as an experimental feature)
How do we handle having the same host, but reachable via different IP addresses/transports in the peers list currently?
I think these problems are kinda the same - I'd resolve these DNS records, and throw all IPs (both address families) into a list of possible paths. For each path, we can then check the pubkey it points to, and then group different paths to the same pubkey (prefer the one with the best metric, but keep the others around as fallback).
This should cover both usecases of people using a dualstacked hostname pointing to a node of theirs, as well as "round robin" usecases, pointing to multiple nodes with different pubkeys.
If we periodically re-resolve, it should also handle DNS changes over time.
In the current behavior the protocol is completely separated from the connection, so opening 2 separate connection between the same peers actually causes the nodes to think they are connected to 2 distinct entities. This is indeed a bit suboptimal (protocol traffic is duplicated over all connections for example). It's something we are thinking about on how to solve it elegantly without tying too many layers together, and should be improved in the future.
As for the DNS resolution, I for sure intend to have periodic resolution. Connecting to all A/AAAA records might be the way to go indeed.
right now it seems like --peers only accepts IP addresses:
It would be very convenient to use hostnames/dns to specify those.