NAT Traversal with hopr-connect

[robertkiel]

• Version: libp2p@0.30
• Platform: Linux / OSX / Windows
• Subsystem: Debian 10 / Big Sur / WSL2

Type: Enhancement

Severity: Low

Description:

At HOPR, we're building a decentralized and incentivized mixnet. We decided to use (and support) libp2p. During the last months, we've created an alternative transport module called HoprConnect that implements the Transport API and the Discovery API and automatically handles NAT traversal by using other nodes in the network - and without requiring any additional* third-party instances such as STUN or TURN servers.

We are right now actively testing the transport module within our testnet(s) to find the last errors and looking for comments and enhancement proposals and intend to start a conversation.

Currently, we are also integrating the corresponding test suites and searching for some feedback as our transport module prevents certain behavior such as self-dials. Next step will be the integration of AutoRelay as we have focused on getting stream handovers and connection upgrades resp. fallbacks working for one connection before adding multiple relays.

*the very first node needs an external STUN server

Steps to reproduce the error:

Use js-libp2p together with js-libp2p-tcp behind a consumer router

Updates

• hopr-connect is now working and tested with js-libp2p@0.30

[vasco-santos]

Hey @robertkiel

Thanks for reaching out! I had a look at HOPR and it seems super useful, really glad that you are working on this.

Regarding HoprConnect, I think that it could be useful for the broader community of libp2p and we would love to add it to our list of supported Transports once it is ready. Let me know if you would like that and when it would be a good time for having a look at the codebase, in order to see if there is something we can recommend for improving it.

Currently, we are also integrating the corresponding test suites and searching for some feedback as our transport module prevents certain behavior such as self-dials. Next step will be the integration of AutoRelay as we have focused on getting stream handovers and connection upgrades resp. fallbacks working for one connection before adding multiple relays.

Let me know if you hit any issues that we can discuss. Regarding self dial, we block it in the API layer.

[robertkiel]

Hi @vasco-santos,

I managed to integrate a few more bugfixes into hopr-connect as well as some refactorings and it seems, as we've tested in our testnets, that the implementation is to able to connect in most cases now. There seem to be still some rare cases where people have problems to connect but the majority seems to be able to establish a connection.

I'd also like to get in touch to get some feedback and kickstart a discussion on how to improve and align more with libp2p and its ecosystem. Potential improvements could include a more formal protocol specification of hopr-connect to allow non-js implementations of it.

I've also seen that you are actively (re-)searching for a decentralized method to do NAT hole punching. I think hopr-connect already provides a working solution for it.

The only point that confuses me a bit on the aforementioned approach is the question whether you intend to reimplement WebRTC's signalling handshake protocol or stick to working libraries such as WebRTC.

Last but not least, I expect it to be relatively easy to feed a HTTP(s) stream into the hopr-connect relay implementation which could pave the way for a browser integration such as asked here

[vasco-santos]

Hello @robertkiel

First of all thanks for all the nice updates here. Being able to use hopr-connect to pave the way to browser-browser connection is super useful!

I'd also like to get in touch to get some feedback and kickstart a discussion on how to improve and align more with libp2p and its ecosystem. Potential improvements could include a more formal protocol specification of hopr-connect to allow non-js implementations of it.

Regarding the current work with NAT hole punching, as well as how we can align for a protocol specification, let me involve in this discussion @aarshkshah1992 who has been working on that initiative.

I would like to see the Limited Relays capable of more things than NAT Traversal, including WebRTC signalling. There are other challenges though that make this feature more complex to land, as browser nodes cannot dial go nodes out of the box. This connectivity issue needs to be addressed so that browser nodes could efficiently leverage limited relays for distributed signalling.

Let us know your thoughts here @aarshkshah1992 . We can also jump on a call to discuss this further later on

[robertkiel]

Let us know your thoughts here @aarshkshah1992 . We can also jump on a call to discuss this further later on

Sounds good 👍

@vasco-santos could you set up a call and send me a link? My business mail address should be given in my GH profile.

[vasco-santos]

After syncing with the team, it would be good to start by creating an issue in https://github.com/libp2p/specs to initiate the discussion and provide visible context about hopr-connect. Could you start by opening an issue there and detail hopr-connect and how it could help other libp2p implementations or compete/integrate within other initiatives?

[robertkiel]

After syncing with the team, it would be good to start by creating an issue in https://github.com/libp2p/specs to initiate the discussion and provide visible context about hopr-connect. Could you start by opening an issue there and detail hopr-connect and how it could help other libp2p implementations or compete/integrate within other initiatives?

Sure. Will do that.

TLDR:

• it is pretty much a drop-in replacement for libp2p-tcp that "magically" handles NAT traversal and churn

[robertkiel]

After syncing with the team, it would be good to start by creating an issue in https://github.com/libp2p/specs to initiate the discussion and provide visible context about hopr-connect. Could you start by opening an issue there and detail hopr-connect and how it could help other libp2p implementations or compete/integrate within other initiatives?

Sure. Will do that.

TLDR:

• it is pretty much a drop-in replacement for libp2p-tcp that "magically" handles NAT traversal and churn

Hi @vasco-santos ,

just finished the issue in libp2p/specs, see libp2p/specs#307

[BigLep]

I'm closing given the issue in libp2p/specs: libp2p/specs#307. Please reopen if there are other items to discuss on this thread.