Upgrade Bootstrap nodes IP version?

[DougAnderson444]

universal-connectivity/packages/frontend/src/lib/constants.ts

Lines 5 to 6 in b136592

	export const WEBRTC_BOOTSTRAP_NODE = "/ip4/18.195.246.16/udp/9090/webrtc-direct/certhash/uEiA8EDMfADmULSe2Bm1vVDSmN2RQPvY5MXkEZVOSyD1y2w/p2p/12D3KooWSmtsbL2ukwVwf8gDoTYZHnCd7sVNNVdMnCa4MkWjLujm"
	export const WEBTRANSPORT_BOOTSTRAP_NODE = "/ip4/3.125.128.80/udp/9095/quic-v1/webtransport/certhash/uEiAGIlVdiajNz0k1RHjrxlNXN5bb7W4dLPvMJYUrGJ9ZUQ/certhash/uEiDYZsZoO8vuTKlPhxvVR5SFwOkbXfjlsmTLUHNlnG24bg/p2p/12D3KooWEymoJRHaxizLrrKgJ9MhEYpG85fQ7HReRMJuEMLqmNMg"

Did we want to upgrade these to IPv6 as well?

[DougAnderson444]

Related to this -- @p-shahi you were noting that there are Browser-to-Browser IPv6 issues:

To help in troubleshooting

1. Is there a Github issue related to this?
2. Should we add the Browser's multiaddress to the frontend UI somewhere, so we can "add Browser Peer"? Right now you'd need to copy it from the backend terminal somewhere, which would work but is hacky.

Looking to see how you are observing & troubleshooting the Browser-to-Browser IPv6 issues currently

[p-shahi]

@DougAnderson444 I created this issue: #64 thanks for the reminder.

Should we add the Browser's multiaddress to the frontend UI somewhere, so we can "add Browser Peer"? Right now you'd need to copy it from the backend terminal somewhere, which would work but is hacky.

Yes that's a good idea, right now, we have to open console, set debug log and grab the listen addr for the browser peer. Ideally it should be displayed in the frontend . Created another ticket here: #65

Let me know if you want to hop on a zoom call to pair together as well

[michaelfig]

I tried libp2p.getMultiaddrs() in my Brave but just get an empty array:

It doesn't look like there are any errors in the browser. Where would I go to diagnose further?

Oh. Nvm. I needed a public peer to be able to get my address. STUN, duh!

[2color]

I'm curious, @DougAnderson444 was there any specific reason or benefit to upgrading to IPv6?

[DougAnderson444]

Other than The fact that IP4 is legacy and has been for several years?

My use case was specifically individuals running a node at home. So they need a globally accessible internet protocol address. As we know, since IP4 addresses are few and far between, getting this global address means a bunch of fancy maneuvers. However, with IP6 they are basically all globally available. So no gateway or mask moves are needed. So that's why I was focusing on IP6. IP6 is a magically convenient way to get a globally addressable address.

Plus, it's the right thing to do. If we can't get IP6 working, and then nobody has a hope.

[DougAnderson444]

Also note that as of several weeks ago, Amazon web services started charging a premium for IP4 addresses. Meaning the cost is a lot higher to run IP4 than IP6

[2color]

Right on!

I recently re-deployed the bootstrap nodes (they hadn't been running for a while). The new node has both IPv4 and IPv6.

In parallel, I've shifted the frontend to rely on delegated routing to discover the multiaddrs of the bootstrap nodes from the peer IDs:

universal-connectivity/js-peer/src/lib/constants.ts

Lines 11 to 12 in 0d235e7

	export const WEBRTC_BOOTSTRAP_PEER_ID = "12D3KooWGahRw3ZnM4gAyd9FK75v4Bp5keFYTvkcAwhpEm28wbV3"
	export const WEBTRANSPORT_BOOTSTRAP_PEER_ID = "12D3KooWFhXabKDwALpzqMbto94sB7rvmZ6M28hs9Y9xSopDKwQr"

The rust-peer is listening on both IPv4 and IPv6 (though due to another bug in the rust peer code, it's seen as listening on many ports).

The go-peer is only listening on the IPv4. I'll open a PR to ensure it's also listening on the IPv6 address.