Is there a way to actually get your own publicly dialable addresses at the application level? E.g. to distribute via an overlay? I’ve read how it’s figured out internally, but can’t seem to find how to access it.
I’m using js-ipfs with an application-specific overlay of peers dialing each other to send direct messages, but right now it’s all over the p2p-circuit, which is obviously undesirable. (That is, if I’m correct in assuming it goes through a third party server?) It seems like webrtc-direct is the way to go, but I didn’t see any examples of where peers’ addresses could come from.
JS currently doesn’t support AutoNat, which is the other post you linked to, so external addresses currently need to be manually specified. As part of the distributed signaling work I am doing, I will likely need to get AutoNAT implemented for js-libp2p, along with some of the other features that should make this much nicer out of the box.
The peer addresses will need to be discoverable over the network. This typically involves dialing to a bootstrap server and doing dht random walks, or connecting to a rendezvous server that also handles peer discovery. Doing direct connections, you will likely need to leverage the former and connect to a bootstrap server.
Ok, thanks, I think I understand now a bit better what the bootstrap servers are doing in the p2p-circuit. They aren’t actually handling the data being transferred, which goes directly from one peer to the other even if they’re both browsers (thanks to WebRTC), but they do handle the signaling part which makes that initial connection between them. So when you dialProtocol('/p2p-circuit/ipfs/Qm...that’s utilizing the bootstrap servers to dial/signal and set up the WebRTC connection, but when you send something over that pull stream (e.g. pull(pull.values([message]), conn, pull.collect(..., it (the message and response) goes directly to that peer?
Is that all right?
Since needing a rendezvous server seems inevitable for now and discovery is handled externally by my app (social network), my biggest concern at this point is scalability, because there are many more things sent than connections opened…