research fula-client overcoming NAT to reach fula-api

[gitaaron]

BOX users' data should be accessible by anyone anywhere in the world.

The main reason we are currently writing the API on top of libp2p is for NAT traversal. There currently is a tremendous effort in the works, however, at present there seems to still be a lot that needs to be worked out for us.

1. I believe webrtc-star requires centralized signalling servers and even with that ~63% may not work?

A single test of connecting fula-client over webrtc-star behind one dev machine's home network to another dev machine's home network fails.

2. Performance issues in using webrtc-star?

3. Using libp2p I can invoke the API outside of my NAT but how will I load the app itself?

IPFS or Filecoin could be one solution, however, problem with that is support for legacy browsers.

Other things to consider -

1. Make use of project flare?
   According to the project flare proposal it only covers ~ 80% of NAT setups - what do we do for 20% where it does not work?
   No JS implementation - right now it seems best NAT traversal is found in GO implementation with QUIC

2. Provide a decentralized service similar to dyndns?

3. Make use of or provide a decentralized load balancing service? Nice thing about this is the scalability problem is also solved. The downside is I am not sure how this is possible whilst maintaining an acceptable level of security. One idea is to consider two scenarios.
   a ) Link is shared with a small private group (scaling is not a problem here but still needs to overcome NAT)

b ) Link is shared publicly (scaling is a problem but security in terms of unwanted access is not a problem)

[gitaaron]

This issue relates to functionland/fula-archived#162 in the sense that a go-mobile native client can vastly improve connectivity since Go is currently the only implementation that fully supports hole punching.

It would be great if we could also have a Go (or maybe Rust since it seems to be not far behind?) libp2p stack working in the browser as well for this reason.