Expose underlying implementation

[wemeetagain]

In Lodestar, we're forced to do make some little wrapper functions to get the types of the default implementations. (And we're just lucky that the types are exported, despite your intention 😂) These default implementations are often necessary to fine-tune or inspect data not available in the generic interface types.

Maybe there's a better way to do this?

See:
https://github.com/ChainSafe/lodestar/blob/unstable/packages/beacon-node/src/network/util.ts#L71-L90

[wemeetagain]

I'd almost say there's no need to have an interface-connection-manager, interface-registrar, etc if there's not even a way to swap in alternative implementations.

[maschad]

I'd almost say there's no need to have an interface-connection-manager, interface-registrar, etc if there's not even a way to swap in alternative implementations.

Agreed. My understanding is that the Connection Manager and Registrar in particular are apart of the core libp2p stack and are intended to have concrete implementations according to the spec. Looking at Go's Base connection manager , it seems to have been implemented that way (as a struct as opposed to an interface).

I would say should there arise a need to have added functionality then a consumer could extend the ConnectionManager or Registrar classes.

[maschad]

#1574 should solve some of the issues we where facing in lodestar, but for this particular method which gets all connections and their associated peer ids , I don't see why we couldn't modify the connection manager interface to expose that connections map.

[achingbrain]

To get all connections, call libp2p.getConnections(). Each connection has a remotePeer property that is the PeerId of the remote node.

[maschad]

To get all connections, call libp2p.getConnections(). Each connection has a remotePeer property that is the PeerId of the remote node.

This would add additional runtime logic which in the case of lodestar negatively impacts performance