libp2p v2 relay functionality is on by default and configurable

[BigLep]

Done criteria: go-libp2p's v2 relay functionality is on by default but configurable. Accompanying docs are present.

Why important: Project Flare will be most successful if we can have sufficient relays present on the network so that there is a large pool of nodes to perform relaying.

Customer:

Notes: relaying nodes won't be advertised to the DHT. That is a future effort.

[aschmahmann]

This seems 👍. The one exception I'd add here is that relaying should not be on for nodes that themselves are NAT'd/require a relay. I suspect go-libp2p will take care of this for us, but in case it doesn't it's something we'll have to consider when dealing with the configurability and what the default mode will be. This seems similar in spirit to the DHT's auto mode.

IIUC the relaying we're talking about here is configurable v2 relaying where the amount of bandwidth donated by peers is fairly minimal. Out of curiosity how difficult is it to setup a few default relays to test the protocol in production first before widely deploying it? If each peer use of the relay consumes minimal bandwidth then using a few centralized relays for the network to start might not be such a big deal. However, I might be drastically underestimating the scales here.

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[vyzo]

we are not going to advertise them to the dht at all; the relay selection strategy in autorelay will change for Flare.

…

On Tue, Oct 19, 2021 at 5:53 PM welcome[bot] ***@***.***> wrote: Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within *two business days*. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers: - "Priority" labels will show how urgent this is for the team. - "Status" labels will show if this is ready to be worked on, blocked, or in progress. - "Need" labels will indicate if additional input or analysis is required. Finally, remember to use https://discuss.ipfs.io if you just need general support. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAI4SSPO4FPIJFXXBYJ5RDUHWA5TANCNFSM5GJLN64Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.