vyzo

> This extends to 'same peer' also right? (This might be implicit in what you just stated, just double checking because I'm new in libp2p.) yes, of course -- the...

> What I'm seeing here is the first dial timeouting before the second one has a chance to hit and I'm trying to figure out how to better guarantee that...

I am not convinced its the transport's responsibility to do dns resolution; and we can pass the domain in a contrext option for websockets. For caching, we should probably rely...

We should also consider that sometimes duplicate connections are legitimate events: - simultaneous connect by two peers, which would manifest as an incoming and outgoing connection at each peer -...

Seems that the most convenient place to implement is the connection manager, as we already have the apparatus for tracking connections and trimming logic.

I propose the following _heuristic_ strategy for deduplicating conns. The only real requirement is that the process is deterministic and two peers running it simultaneously converge to the same connection...

Note that maybe we should reverse 2 and 3, so that we always handle simultaneous connect in a principled manner, regardless of number of streams.

@raulk @Stebalien thoughts?

I very much dislike the idea of going with the flavour of the day; applications should be free to use whatever they want, and we already have two different systems...

I would like to propose something different. How about a _monitoring_ interface, that can also be used for collecting metrics? That way the users can do whatever they like, and...