If I need only an outgoing connection, why libp2p should be start()'ed to listening for incoming connections?

[overphoenix]

I think it is worth reconsidering the need to start the node in the case of client-server scenarios, when one node dials another, but the first one (connection initiator side) does not need to be start()-ed.

For example, I need to connect to a public network from private network or if we have two nodes on the same host - first node as server and second node as client. Current implementation consumes more resources than it needs and in most cases is not secure.

The architecture of the libp2p node should allow to do this, since in a large way this does not contradict anything.

P. S. May be this topic has already been discussed, but I did not see how to get workaround using current js-libp2p implementation.

[overphoenix]

As I understand, no one is particularly in a hurry to discuss this moment ))

Maybe then I should make a pull request with these changes?

[jacobheun]

I think this is a reasonable thing to allow. The addition of the no dial when offline is quite old, #43. I don't have any context to why it was added. While there are scenarios where applications may want to avoid dialing, this is a reasonable check that can be added to the application (js-ipfs does this).

The stats system in libp2p-switch is an example of something that consumes a lot of resources during startup that likely isn't necessary to run, depending on what you're using it for.

A caveat of this is losing things connection management if you don't start the node, but if you really don't need any of that, a bare bones libp2p implementation shouldn't block you from dialing.

I'm open to a PR for this, it will be a breaking change. @vasco-santos any thoughts?

[achingbrain]

This is an interesting use case that would open up scenarios like curl or wget on the command line for sending packets of data to peers.

When the node is started lots of things happen like contacting DHT peers or interacting with the datastore (via the peer store, etc) so it may not be possible without some extra overhead.

It's not something the current implementation is designed around but there's no reason it shouldn't be possible if you have a multiaddr to connect to.

To move this forward I would suggest creating a demo app that just uses a minimal set of components to make the connection (the tcp transport for example), this will bottom out what's required to make a connection and we can use that to inform a refactor of the codebase to allow for offline dialing.