How do I connect 2 remote nodes?

[ghost]

Hello, I'm interested in using P2P as an alternative to having a server.

I'm wondering how I could connect 2 nodes in two different networks and possibly different countries even.
There seems to be some documentation about this on https://docs.libp2p.io/concepts/nat/.
The first thing, automatic router configuration, does not really seem to be implemented yet in most implementations (notably the Rust one) so that's probably not an option for now.
One common way seems to be STUN where you don't use a server for the primary communication but only for the initialization: the address exchange for the nodes to find each other, if I understood that correctly. After that they communicate directly without any server.
There are a few public STUN servers available and I was wondering if there an example somewhere where I could basically put in an address of one of these STUN servers at https://gist.github.com/mondain/b0ec1cf5f60ae726202e or something and then have the two nodes running the same program connect, wherever they are? Where can I learn about that and how do I get started with making use of STUN with rust-libp2p?

[mxinden]

Today rust-libp2p does not (yet) support hole punching nor UnPnP. You can follow the current progress on hole punching here #2052. I would hope for basic hole punching functionality in rust-libp2p by the end of this year / beginning of next year.

[ghost]

Thank you very much.
Currently I'm evaluating whether I should wait for this library to have support for STUN servers/ICE/hole punching etc. or whether I should use something like https://crates.io/crates/webrtc-ice + std::net instead.
So as an argument for libp2p I was wondering if libp2p would in the future potentially have more sophisticated remote peer finding than if I did the p2p naively myself with something like https://crates.io/crates/webrtc-ice + std::net? Will libp2p cover more cases than that and work with more users because it can get through more firewalls and stuff maybe?
In that case it may be better for me to wait for libp2p's support. Do you know anything about that?

[mxinden]

Arguments speaking for libp2p:

• Will support many transport protocols in the future (TCP, QUIC, WebRTC, Websocket, ...)
• Allows for decentralized hole punching. If I am not missing something ICE always depends on centralized TURN and STUN servers.
• Provides many more protocols, e.g. Kademlia, Gossipsub, ... (see https://github.com/libp2p/specs/)

[ghost]

Thank you! That sounds good.