Allow transport listener to return multiple multiaddr about go-libp2p-core HOT 2 CLOSED

Hey @Jorropo! Thanks for spearheading the work in getting the uTP transport up and running with the latests versions of go-libp2p. Very much appreciated!

The multirepo vs. monorepo discussion does crop up frequently. We continuously take steps toward a more cohesive DX; namely in the last months we consolidated interfaces into go-libp2p-core from 12+ repos. Now we're consolidating issue tracking into the top-level go-libp2p repo.

Re: the concrete issue here, we can't make transports resolve "bind all" and magic addresses, because that's the wrong layer and that would leak concerns. In other words, we'd be making the OSI layer 4 deal with concerns of OSI layer 3.

That's why there's this inversion of control in place. Transports listen on a single logical address, which when resolving it may unpack into several physical addresses.

If you genuinely want a transport to listen on multiple logical addresses, you'd instantiate that transport more than once, each with a different listen address.

Would you mind explaining how the current handling of bind all addresses is causing trouble in go-libp2p-utp-transport?

from go-libp2p-core.

@raulk currently there is none in go-utp-transport, returning /ip4/0.0.0.0/udp/<port>/utp works well and get resolved, I have a problem with the i2p-sam transport I want to make after the utp one.

The problem is i2p have 2 way to encode address, garlic32 and garlic64 (the first one is a hash of the second, to use it you will have to do a lookup in the i2p dht).
So yes in this case we can do the same things, we do with ip and return garlic64 and resolving later elsewhere to get the garlic32 version, but that not plug and play and I don't think i2p is gonna be only case requiring that and I think its better to just let transports manage that by them self to be more future proof (or maybe not for special known case (such as ip or ether)).

from go-libp2p-core.