raulk

@Stebalien > Also note: forcing the dial to complete means we can't optimize the dial later. In an ideal world, the AutoNAT server would just (with TLS/QUIC): 1. AFAIK, the...

@Stebalien > This saves the AutoNAT server from having to do any fancy crypto beyond computing the initial DH params, making this service significantly more efficient. This honestly sounds like...

@Stebalien > If we do go with this, I'd like to avoid unnecessary crypto. Instead of a per-request nonce, we should just let the AutoNAT server sign their main key...

The benefit of a higher-level message (vs a FIN packet) is that we can model a "disconnect reason", useful for debugging and future extensibility. For example, the [devp2p stack in...

It seems odd to place these control messages in a protocol called "identify". Other applications call this "wire protocol" or "control protocol". Maybe a more generic protocol could subsume identify?

@Stebalien those feel juxtaposed. Many tiny protocols != one (coarse-grained) connection management protocol, right? May boil down to terminology, though. Medium-term, I do see a `/p2p/wire/nnn` protocol that subsumes: *...

IMO we will need a control stream, and it should be the swarm that opens that stream before handing over the connection to the libp2p stack. Reason: by introducing [connection...

@bigs – how is this going? do you need a review from me or should I wait for the next iteration? In the latter case, when is it due, so...

@bigs > i think the transport is still necessary (you still have to listen somewhere in your code) Hm, I think listening is not necessary. I think of this as...

The connection manager currently works with hard bounds set by configuration. Do you think it’s feasible to “sense” appropriate limits from the environment by allowing connections to be alive until...