browser-to-browser connectivity with webRTC and pubsub (gossipsub)

[benjaminpreiss]

Dear all,

I have been working on an example to showcase browser to browser connectivity. The goal is to subscribe to a topic and display the messages published by other peers on that topic.

Also, I don't want to host a relay server myself, but instead use a public relay server hosted by someone else for now.
For this, I built a frontend that helps to connect two a publisher/server and a subscriber/client:

To reproduce, just clone the repo, then cd experiments/ipfs, yarn and yarn dev.

As you can see in the above screenshots, I test this in two independent incognito browser windows, one acting as a server and one as a client.

Now I have two problems:

• The peers only sometimes connect to each other and the connection is not very stable
• Even when the peers connect, the client peer does not display the message published by the server

I guess it has something to do with the libp2p configuration or my other code dealing with connectivity, but I can't figure out what the problem is... Can someone here help me? I think it would be great for others as well to know how to do this :)

[benjaminpreiss]

... I took the list of bootstrappers from the default helia bootstrap nodes.

[benjaminpreiss]

Hello all!

Can you maybe point us in the right direction, as this is a blocker for our project :/

That would help us a great deal 🙏

[justin0mcateer]

I am using the library in the same way except using private relays instead of public nodes. First, I will say, it absolutely can be made to work. Unfortunately, there are still quite a few landmines in the process.

From my experience, you will need to enable 'debug' output in your browsers
localStorage.debug = '*'
or, if you want all the detail:
localStorage.debug = '*:trace'
and prepare to spend quite a bit of time figuring out where things are going wrong, the possibilities of which are many and varied.

A couple of specific points:

1. You seem to have a lot of potentially superfluous modules and services enabled in your configuration. If you don't know you need it, or know why you need it, get rid of it. Try to start with nothing and build up the pieces you need one at a time. For example, it's not clear to me why you would need the webRTCDirect transport or the circuitRelayServer and autoNATService services.
2. When using Circuit-Relay, I had to give up on the AutoDialer (connectionManager.minConnections = 0) and manage dialing to relays and peers in my application level code.
3. I ran into issues using Mplex handling StreamResets (which are a regular occurrence with Circuit-Relay) and would not recommend using that at all, especially in your stated scenario.

[2color]

Hey @benjaminpreiss,

Since this issue is not directly related to this repo, I'm closing it.
If you still have questions, try the js-libp2p GH discussions or the libp2p forums.

FYI, it's hard building js-libp2p browser apps that don't have dedicated bootstrappers that can help relay gossipsub messages, in case browser-to-browser connections don't work.

I'm working on polishing the browser-to-browser story in #95.

Besides that everything that @justin0mcateer said is on point. I'd add that at this point there's no point in using Mplex. Just use yamux

from docs:

If you need a dedicated muxer, Yamux should be used (overall, QUIC should be preferred over TCP).. Yamux natively supports flow control, it is better suited for applications that require the transfer of large amounts of data.
Until recently, the reason mplex was still supported was compatibility with js-libp2p, which didn’t have yamux support. Now that js-libp2p has gained yamux support, mplex should only be used to provide backward-compatibility with legacy nodes.