Feature Request parameter to get peers added automatically

[Mik-TF]

Feature Request

Exploring Mycelium, I just set an SSH connection via Mycelium between two machines, quick and effective. It's just so cool. While doing so, I tried different peers and I rely on what is written in this README.md for example of peers. I was thinking, it is great to use the peers argument with few peers:

mycelium --peers tcp://188.40.132.242:9651 quic://185.69.166.8:9651

That being said, could it be possible to add some parameters, for e.g. to fetch all peers available, all IPv4 peers available, all IPv6 peers available, all tcp peers available, all quic peers available, and combinations of those, etc. e.g.

mycelium --peers all # this would be all: ipv4, ipv6, quic, tcp
mycelium --peers all ipv4
mycelium --peers all ipv6
mycelium --peers all tcp
mycelium --peers all quic
mycelium --peers all ipv6 quic
mycelium --peers all ipv6 tcp
mycelium --peers all ipv4 quic
mycelium --peers all ipv6 tcp

Implementation

I guess Mycelium would need to check all peers in the network. Perhaps one basic peer would be needed to first connect to the network? E.g.

mycelium --peers all tcp://188.40.132.242:9651

Or we could set a basic list of peers within every Mycelium release, and it tries any of them until at least one works, then it scans the whole network and connects to all peers.

Modalities

Perhaps fetching all peers is too much so it could be: find and connect to 10 peers within the given parameters (e.g. mycelium --peers find=10 ipv4, etc.)

Most surely the way I write commands is wrong, but it's to give an idea.

From what I read there isn't yet such suggestion, but if there is, feel free to close the issue.

Thanks!

[LeeSmet]

In general, this is currently not doable since mycelium does not learn, nor care, about connection details of underlays of nodes in the network (except of course for the direct peers). From the protocols perspective, all it has is a bunch of connections (peers), which announce routes to overlay subnets, from which it then selects the "best" route (i.e. this packet should go on this connection).

In the (far) future, there might be a case to implement some form of network topology discovery. The main goal there would be for nodes to learn about the network, so they could potentially "shorten" the distance of frequently used paths by connecting to intermediate nodes in the path/the end node directly (as we generally assume that the triangle inequality theorem is applicable for route latency). Though I should stress that this is something which came up once that might be interesting, and is in no way a commitment to a future feature.