dirkmc

Looks like it's on the right track @vasco-santos 👍 I left a few comments for minor things in the code. I wonder if it would make sense to persist the...

Agreed, that makes sense to me. @jacobheun I see you applied the label `difficulty:easy`. Maybe I can take a stab at doing this myself. Could you give me a quick...

Thanks for the detailed response! I have a question: You said that `once we dial, we should consider that an outgoing connection even if it was originally incoming`. Should we...

That seems simpler to me 👍 So just to confirm: - there are two types: incoming / outgoing - we don't ever change the type of a connection - when...

@jacobheun it seems that when an outgoing FSMConnection receives an incoming connection, [it adds itself to the ConnectionManager](https://github.com/libp2p/js-libp2p-switch/blob/v0.41.3/src/connection/index.js#L365). But its connection type is `Outgoing`. Our use case is that we...

Ah, thanks @jacobheun that makes sense. As I'm going through updating the tests for this change I've noticed a couple of things: - When disconnecting we [end the muxer](https://github.com/libp2p/js-libp2p-switch/blob/v0.41.3/src/connection/index.js#L267) which...

Fixed by https://github.com/libp2p/js-libp2p-switch/pull/298

This sounds like a good improvement to connection management 👍 Ideally connections would be prioritized by the service the remote peer provides, and there would be a mechanism to discover...

Hi, any progress on this? Thanks, Dirk

Hi, not sure if I'm missing something here, but it seems like the solution is quite simple. At the moment when pool=true, a new db connection is taken from the...