feat: Support WebRTC Browser-to-Browser

[DougAnderson444]

I have tried to add Gossipsub to the echo example here: https://github.com/libp2p/js-libp2p/tree/master/packages/transport-webrtc/examples/browser-to-browser

I've posted a repro here: https://github.com/DougAnderson444/libp2p-gossipsub-browser-to-browser

Steps are:

1. run a relay server
2. connect first browser to the relay
3. connect the 2nd browser to the 1t browser's circuit multiaddr
4. connect the 1st browser to the 2nd browser's circuit relay addr
5. Drop the relay server <== this is where gossipsub no longer works
6. Try to exchange messages between browsers

If you follow the instructions in the example, echo works even when the relay server is dropped. But unfortunately, when the relay is gone so is the gossipsub functionality.

I don't know enough about the inner workings of gossipsub to troubelshoot this, so I could really use some assistance solving this.

[justin0mcateer]

I am investigating this issue. GossipSub ignores any new connections to a peer if it already has a connection to that peer:
https://github.com/ChainSafe/js-libp2p-gossipsub/blob/master/src/index.ts#L745

I am going to take a stab at making the stream management more robust by using the AddressSorter mechanism to determine which connection is more 'preferred'.

One would think that once the Relay connection dies, that GossipSub would attempt to re-connect to the peer via the remaining (WebRTC) connection. Not sure why that doesn't happen I will investigate that further today.

[Marcel-G]

I think this issue got a little worse since libp2p/js-libp2p#1890
Gossipsub will now not send over relayed (transient) connections and it does not use the upgraded webrtc connection as mentioned in this issue. Effectively it doesn't send at all

[justin0mcateer]

I have managed to get it working, but it wasn't easy. The biggest problem is that GossipSub tries to connect in peer discovery, but it gets aborted because it is a transient connection. The default connection logic is that GossipSub basically never tries again.

One work around to this is to enable 'directPeers' in the GossipSub config, this will cause GossipSub to attempt to connect to the listed peers every heartbeat (1 second by default).

[Marcel-G]

@justin0mcateer does that workaround involve knowing the directPeers peer ids and multiaddrs up-front or do you have a way of doing this dynamically?

[Marcel-G]

@achingbrain I see that runOnTransientConnection was added to handlers, but is it somehow relevant for topologies also?
It feels a little strange we would get onConnect with a connection that cannot be used with the protocol

js-libp2p-gossipsub/src/index.ts

Lines 589 to 592 in a2981f9

	const topology = {
	onConnect: this.onPeerConnected.bind(this),
	onDisconnect: this.onPeerDisconnected.bind(this)
	}

[justin0mcateer]

I agree. I was thinking about whether it would make sense to have the Identify service filter out 'non-transient' protocols on transient connections. To minimize superflous new stream requests. Or maybe have GossipSub use 'dialProtocol' and filter connections based on whether the protocol is transient.

…

________________________________ From: Marcel Gleeson ***@***.***> Sent: Tuesday, August 22, 2023 10:05:25 AM To: ChainSafe/js-libp2p-gossipsub ***@***.***> Cc: justin0mcateer ***@***.***>; Mention ***@***.***> Subject: Re: [ChainSafe/js-libp2p-gossipsub] feat: Support WebRTC Browser-to-Browser (Issue #448) I see that runOnTransientConnection was added to handlers, but is it somehow relevant to topologies also? It feels a little strange we would get onConnect with a connection that cannot be used with the protocol https://github.com/ChainSafe/js-libp2p-gossipsub/blob/a2981f956d1f427fae9deb9c769f0baab0db5d26/src/index.ts#L589-L592 — Reply to this email directly, view it on GitHub<#448 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAT4Q7OMG5VGD2SU7HCWQSTXWTDDLANCNFSM6AAAAAAZ6ZCFOY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[achingbrain]

Please can you try with [email protected] (just released) - it has the fixes for protocol handlers & transient streams incorporated - by default gossipsub will no longer run over a transient stream, only direct connections.

[wemeetagain]

closing as stale