Configure Mobile framework/binary to use relay-enabled bootstrap nodes

[placer14]

Mobile framework and binary (both) package need to use alternative bootstrap nodes which will have relay support enabled for the OB network. In the short-term, we would like to override the mobile framework/binary init to use alternative bootstraps endpoints which will be stored in config and used specifically by mobile framework/binary builds. In the long-term, we would like to be able to migrate these mobile nodes to use new endpoints without impacting desktop nodes.

Implementation:

• We will hardcode the desired bootstrap endpoints for the mobile package pending the final list of addresses being ready, ensuring they ignore any config-based value (as they aren't user editable for mobile anyway)
• (optional) might be worth indicating in the logs which bootstraps are being connected to by the node on startup to ensure the hardcoded values are being used and for later forensics?

Original requirements:

1. Replace bootstrap nodes with phase-1 nodes for mobile only.
2. Finalize plan for replacing bootstrap nodes with Experimental phase-1 nodes on only mobile, and be ready for a migration on all nodes to replace bootstrap nodes to Stable phase-2 nodes.

[tyler-smith]

Experimental relay 1 is available for testing: /ip4/138.68.10.227/tcp/4001/ipfs/QmWUdwXW3bTXS19MtMjmfpnRYgssmbJCwnq8Lf9vjZwDii

/ip6/2604:A880:0002:00D0:0000:0000:219D:9001/tcp/4001/ipfs/QmWUdwXW3bTXS19MtMjmfpnRYgssmbJCwnq8Lf9vjZwDii

[tyler-smith]

Relay 2: /ip4/157.230.59.219/tcp/4001/ipfs/QmcXwJePGLsP1x7gTXLE51BmE7peUKe2eQuR5LGbmasekt

/ip6/2604:a880:400:d1::c1d:2001/tcp/4001/ipfs/QmcXwJePGLsP1x7gTXLE51BmE7peUKe2eQuR5LGbmasekt

[hoffmabc]

Brian's Relay

/ip6/2604:a880:400:d1::99a:8001/tcp/4001/ipfs/Qmb8i7uy6rk47hNorNLMVRMer4Nv9YWRhzZrWVqnvk5mSk /ip4/206.189.224.90/tcp/4001/ipfs/Qmb8i7uy6rk47hNorNLMVRMer4Nv9YWRhzZrWVqnvk5mSk

[placer14]

We have NATed nodes using the above bootstrap nodes with configurations which should enable autorelay to work, however we are not seeing these nodes announcing their relay paths. This is the process we are expecting and are trying to confirm is happening on our network. Investigating further.

[placer14]

I think our network configuration is sufficient for supporting autorelay on our nodes. I see a NATed node actually finding other opt-in relays, selecting a few at random and completing the connection to them. The node then proceeds to update it's published addrs but those published addrs don't end up appearing elsewhere on the network. Even the node which is the providing relay does not return the relay circuits in this response. Next is to investigate why the addr update to the rest of the network is failing.

Also notable from tests is that autorelay took approximately 8 minutes from startup to final relay connection via several "stream close"s and "protocol not supported"s before finally resolving a connection and attempting to notify the network of the new relay multiaddr.

[placer14]

Turns out the pushed/updated relay multiaddrs were not valid due to an OpenBazaar-specific patch which was handling the migration of our CIDs to line up with standard IPFS CIDs. Upon reverting the patch (which can be deprecated and removed, according to @cpacia), valid multiaddrs were then propagating. Still, the autorelay process can take between 5-10 minutes depending on the responsiveness of the DHT swarm and how well-connected the node happens to be on startup.

The next step is to investigate how to get the mobile nodes to automatically connect and announce themselves as available via the relay without waiting for autorelay to publish updates.

[hoffmabc]

This is done isn't it @placer14 @cpacia ?

[placer14]

I was able to get the node to use our relays without autonat or autorelay being used. but the relayed multiaddrs don't propagate from the node. It had to be put on hold for other tasks.