IStreamsend/receive messages through some kind of abstracted channels, multiplexer-agnostic
At least I think this one is applicable.
For example, the persistent metadata component could automatically add peer ids and addresses to its registry whenever a new peer connects, or a DHT module could update its routing tables when a connection is terminated.
To support this, it's recommended that libp2p implementations support a notification or event delivery system that can inform interested parties about connection lifecycle events.
Also related to connection management, libp2p has recently added support for QUIC, a transport protocol layered on UDP that can resume sessions with much lower overhead than killing and re-establishing a TCP connection. As QUIC and other "connectionless" transports become more widespread, we want to take advantage of this behavior where possible and integrate lightweight session resumption into the connection manager.
ResumableConnectionor similar for resumable transports like quic
IResumableConnectionin the abc module so application code can see if the underlying connection is resumable, though this is superficial and only applicable in very specific use-cases