Oh ok, it explains how PubSub can work between browsers then.
Well yes, otherwise there would be no point in implementing WebRTC transport in libp2p, we could do everything with WebSocket and connect all browser nodes with Go or Nodes.js nodes.
I can take me as an example, what I want to do is a completely peer-to-peer web game, so I have to use WebRTC. But I don’t even want STUN, TURN or signaling servers, so I dismissed the PeerJS library because it uses a connection broker server.
But I don’t want to reinvent the wheel either. The idea I gave here only applies if there is a large enough network that can do relaying to replace STUN and TURN serverlessly, so libp2p is perfect for that.
When I can leverage the speed of direct browser-to-browser WebRTC connections, I don’t see why I would still use relay for the communication in my game. I don’t know if PubSub (that uses relay if I’m not mistaken) would be able to handle all the traffic of a web game, and I don’t know if there is someone in the libp2p network who would be willing to sacrifice their bandwidth so that every communication of the game would be relayed through their go-libp2p node.
I don’t think that’s true, it would be like saying that Go nodes cease to exist when the computer shuts down. It doesn’t happen because the public/private key pair persists on your computer’s hard disk (in the local storage of the browser in the case of js-libp2p).
But I would agree that connections (and not nodes) are extremely short-lived on the browser, because as soon as you close your browser, your NAT could close the port it has opened for you. But when you reopen your browser and relaunch your libp2p node using the same key, you can connect to the swarm and your friends can contact you again because you will have the same /p2p/ key, although your multiaddr might have changed (especially the /tcp/ part). You just have to do NAT hole-punching and peer discovery again.
But even if nodes were extremely short-lived on the browser, I would say it’s not really a problem 90% of the time because the need is not the same between the browser version of libp2p and the Go version. In Go, you want to have a full-fledged client that is stable, can do automatic port forwarding etc. while in the browser most of the time you want to use libp2p as an abstraction of the WebRTC API to directly connect browsers between them and do clever apps like a peer-to-peer chat or a collaborative editing application. Often, you don’t care if your libp2p instance is not the same when you restart your browser.