Strategy when double NAT

hi everyone.

So I made this social file sharing app (http://arbo.re/).

Basically it’s working by running a go-ipfs node and having each ‘identity’ generate a keypair. Identity information are then published on ipns using that keypair. Once you get these informations, you can start sending message between nodes using pubsub, get notifications and so on …

More details here: https://github.com/ipfs/go-ipfs/issues/3866

Problem is, my real world tests shows that there is still connectivity problems in double NAT case (which would be most of the time for this project) for ipns, pubsub and normal block queries. Basically, two person would not be able to resolve the ipns entry (or it would take minutes), pubsub messages would not get through.

How can I work around or reduce this problem ?

Some questions:

  • Do you control the ipfs node that your app uses? (does it run init?)
  • Do you run your own bootstrap nodes for users of your app?

If the answer to both of the above is yes, you can have your bootstrap nodes enable relaying, and then have your app nodes announce a relay address. This should result in most users relaying connections through your bootstrap nodes, and should generally improve connectivity at the cost of centralizing the connections a little bit.

19:37 <whyrusleeping> So the only real solution to double NAT is relay
19:37 <whyrusleeping> the hard part is *detecting* double NAT
19:37 <whyrusleeping> once you detect it, you can relay through other nodes to the target
19:39 <Bat`O> the problem is that i don't know the node ID i want to reach
19:40 <Bat`O> I only know the public key I want to reach
19:40 <Bat`O> or in the pubsub case, the topic i want to get message from
19:41 <whyrusleeping> You don't know the node ID but you know the public key?
19:41 <whyrusleeping> is the public key different than the node ID?
19:41 <Bat`O> yes
19:41 <whyrusleeping> hrm
19:41 <Bat`O> you can have different identities on the same node
19:41 <whyrusleeping> right
19:43 <whyrusleeping> (responded a bit in the thread)
19:45 <Bat`O> do you mean that if both node A and B configure C as a relay, they will somehow be able to connect ?
19:45 <Bat`O> even without explicit A --> C --> B relay config ?
19:45 <Bat`O> and back ?
19:46 <whyrusleeping> If C says "hey, i'm a relay"
19:47 <whyrusleeping> and A and B both announce relay addresses, when A tries to connect to B, it will automatically use C
19:47 <Bat`O> ho nice
19:47 <whyrusleeping> its currently a little too enthusiastic, and will sometimes make a relay when it could have made a normal connection
19:47 <Bat`O> that could solves a lot of problems
19:47 <whyrusleeping> yeah, we're excited about it
19:48 <whyrusleeping> currently we're doing a refactor of libp2p to allow for supporting QUIC as a transport
19:48 <whyrusleeping> but after that, we're going to push for smarter relaying