PubSub to connect browsers

Users and Developers js
1

I have seen this interesting video on how to build a chat application between browsers using PubSub:

And below this video I saw a comment asking how PubSub works to connect browsers. I will paste it here:

How does it work? Does pubsub use WebRTC, and if so isn’t WebRTC centralized in how it connects peers; doesn’t it require a server to initially connect peers? And if so, which server is it using? Does IPFS host a STUN/TURN server setup that is being used for every IPFS client? I’d like to see a video that goes into the details on the implementation of jsipfs

It’s true that it begs several questions on how libp2p handles everything and what is the network topology. After reading the libp2p PubSub documentation, I’m not totally sure but I think that I kind of get it:

  • first, the local browser libp2p node connects to bootstrap peers,
  • after bootstrapping, the browser libp2p node does ambient peer discovery (it can only connect to “server type” peers, i.e. peers that support dialing through WebSockets, HTTP or a rendez-vous point, so bye-bye 99% of all the browser peers),
  • then the messages of the application of the video are relayed between peers using circuit relay.

So to answer this Youtube comment, PubSub in the browser uses circuit relay instead of WebRTC. I would like to know if (or rather where) I’m mistaken in my explanation.

If it is true, it would mean that:

  • Firstly, in order for this demo application to work, the messages must be routed through several intermediary nodes (that are most likely go-libp2p nodes and not browser nodes at all) that are not interested in our PubSub topics;
  • Secondly, the different browsers do not communicate directly between themselves (because the only way to directly connect 2 browsers using libp2p is to use the /p2p-webrtc-star/ transport that uses a signaling server, so it wouldn’t work in an out-of-the-box application like this one).

The first point is not really a problem, it is in the PubSub specification: you don’t have to know the publishers when you are a subscriber and you don’t have to know the subscribers when you are a publisher. But the network traffic induced by our application can be a problem for these intermediary nodes that have nothing to do with our application. Besides, I don’t think PubSub has a high enough throughput to handle the communications of a real-time peer-to-peer web game for example.

So that brings us to the second point, in this case a direct communication between browsers using WebRTC is preferable than PubSub, because it is faster and doesn’t require intermediary nodes. I have made a suggestion for a new libp2p transport that would harness the speed of WebRTC while staying completely decentralized (no rendez-vous point):

I know, you can already create WebRTC connection between browser by sharing the SDPs via PubSub of libp2p, but you cannot create libp2p connections that use WebRTC with the protocol I described. I am sure that libp2p developers have already thought about this before.

An additional a bit off-topic question: Is there some kind of security for PubSub, in case a topic name becomes very popular and it becomes interesting for an attacker to take over this topic? It would also prevent a topic to be used for 2 differents applications. Is there some way to make “allowed publishers”?

2

Here is a thread about replacing webrtc-star by something more decentralized:

I don’t think there is anything preventing anyone from publishing in the topic. But you can drop everything that is not from your whitelist at application level. You may even be able not to relay messages from peers that are not from your application whitelist.

1 Like
3

Thank you, I was pretty sure that wasn’t a new idea at all for js-libp2p developers. The only question remaining is, when will we have a stable implementation of it? The following resources are also useful:

So to be sure, does PubSub on the browser indeed uses circuit relay, or does it use WebRTC?