Question: Browser to browser direct

[acolytec3]

Would it be possible to leverage the code from this to enable browser to browser direct webrtc connections with libp2p?
https://github.com/manthrax/serverless-webrtc

I've tested this and it seems to work between Chrome and Firefox browsers at least on a local network. I'm working on a webapp that's intended to only run between browser-based libp2p nodes but is currently dependent on STAR servers and this seems like it could be the answer?

I'm going to read up on it more but I'm a novice when it comes to WebRTC so not sure I have the chops to implement it myself.

[vasco-santos]

Hello @acolytec3

Thanks for reaching out. We have in our roadmap improvements on this regards. The current limitation about browser to browser webrtc connections is the lack of peer discoverability. If you look into the serverless-webrtc, the WebRTC offer/answer exchange is performed manually by the users, for example via IM. So, what happens is that a manual peer discovery is needed, where someone running a given peer will need to provide the offer/answer of the WebRTC negotiation via a third party service.

We are looking into a distributed signalling approach that will circumvent this limitation by leveraging other libp2p peers in the network that both parties will need to know in advance. You can read more about this planning in libp2p/js-libp2p#385 (comment).

Currently, I am working on finishing the Rendezvous implementation in JS and I hope we can continue that effort over the next months. For the time being, we recommend to use the star servers as we will be providing migration guides to this new approach once we have it in place.

If you want to help with this let me know. We can discuss on a more actionable plan for this

[acolytec3]

Thanks for the comment. In my particular app's use case, WebRTC offer/answer exchange is performed manually by the users, for example via IM would be perfectly acceptable as the premise of the app as currently written is two people standing next to each other start the app, scan a QR code containing the public key of the person they want to start a chat with, and then the app uses the scanned public key to dial the peer. The unspoken premise in this is that the two nodes have already found each other via the signalling server.

If the app could include the signaling offer in the QR code that's generated, that would eliminate the need for the star server for peer discovery/establishing the direct connection in my use case. That said, supporting peer discovery between browsers-based nodes in this way that doesn't seem to be on the roadmap at present. Is that an accurate inference?

[acolytec3]

I've been reading/thinking about this a little more since earlier and I think the use case I outlined above isn't really that useful in any other than that very limited domain of two people/nodes in physical proximity and able to exchange discovery info so will drop that direction from my project as I have a vision to generalize it to use pubsub and some sort of shared keys to allow for ephemeral, secure group chat.

That said, I could definitely be interested in contributing more to the ongoing work beyond the couple of small doc tweaks suggested so far. I'm not sure I have the technical chops to dive into the deep end of working on the rendezvous implementation but always happy to pitch in if there's something bite size I could start on.

[vasco-santos]

If the app could include the signaling offer in the QR code that's generated, that would eliminate the need for the star server for peer discovery/establishing the direct connection in my use case.

I am not 100% sure on this without trying it out, but I think both parties need to "receive" the offer. For instance, I would share my SDP offer with you via SMS and you would send me yours via SMS. Then, we would need to trigger it both for establishing a connection.

supporting peer discovery between browsers-based nodes in this way that doesn't seem to be on the roadmap at present. Is that an accurate inference?

It is not planned, but I honestly think that we should support it given that in some use cases this might be nice to have,

I've been reading/thinking about this a little more since earlier and I think the use case I outlined above isn't really that useful in any other than that very limited domain of two people/nodes in physical proximity and able to exchange discovery info so will drop that direction from my project as I have a vision to generalize it to use pubsub and some sort of shared keys to allow for ephemeral, secure group chat.

I would recommend you start by using https://github.com/libp2p/js-libp2p-relay-server , which already comes built in with pubsub discovery. I created an example recently to use this: libp2p/js-libp2p#855 . Combining this with auto relay https://github.com/libp2p/js-libp2p/tree/master/examples/auto-relay enables you to quite transparently achieve websocket browser to browser connections, as well as using Node / go <-> Browser using websockets. This allows you to easily scale the relay server into a fleet of relay servers that would enable your app nodes to leverage it in a distributed fashion to discover and connect with peers.

The downside is continuous relay of the connection. We have in our plans to upgrade a relay connection into a direct connection, which would mean the relay part would just be for establishing the connection libp2p/specs#173

On the other hand, webrtc-star automatically results in a direct connection after the SDP offers are exchanged, but there is the centralization drawback of the star server.

That said, I could definitely be interested in contributing more to the ongoing work beyond the couple of small doc tweaks suggested so far. I'm not sure I have the technical chops to dive into the deep end of working on the rendezvous implementation but always happy to pitch in if there's something bite size I could start on.

That would be great and super helpful. I would recommend looking through https://github.com/libp2p/js-libp2p/issues and if you are interested in helping out with any issues labelled as ready that are easier and interesting for you just let me know. You can mention me there and we can also discuss possible designs if needed.

Creating examples and docs around things that you try for your project are also important for the broader community.

[acolytec3]

I would recommend you start by using https://github.com/libp2p/js-libp2p-relay-server , which already comes built in with pubsub discovery. I created an example recently to use this: libp2p/js-libp2p#855 . Combining this with auto relay https://github.com/libp2p/js-libp2p/tree/master/examples/auto-relay enables you to quite transparently achieve websocket browser to browser connections, as well as using Node / go <-> Browser using websockets. This allows you to easily scale the relay server into a fleet of relay servers that would enable your app nodes to leverage it in a distributed fashion to discover and connect with peers.

The downside is continuous relay of the connection. We have in our plans to upgrade a relay connection into a direct connection, which would mean the relay part would just be for establishing the connection libp2p/specs#173

I wonder if it may be possible to just run a go-based relay server via gomobile in the background inside a mobile app and package up the browser-based nodes to point to that gomobile server running locally. The specific use case I've built for is ephemeral connections where the nodes only live as long as the app is open and ideally we don't have any points of centralization since the users will be able to establish the initial connection either via an SMS/QR code and then maintain that connection only as long as is needed. For this particular use case, needing to maintain centralized relay servers doesn't really gain anything over the star server implementation I currently have since all I really want is for peer discovery to be able to happen as flexibly as possible since here again, these are short-lived browser based nodes and the prototypical use case is two friends open the app, generate new nodes with fresh PeerIDs, exchange contact details via QR code, and then go their separate ways and are able to maintain a secure communications path for a limited period of time, burner phone style.

[acolytec3]

That would be great and super helpful. I would recommend looking through https://github.com/libp2p/js-libp2p/issues and if you are interested in helping out with any issues labelled as ready that are easier and interesting for you just let me know. You can mention me there and we can also discuss possible designs if needed.

Creating examples and docs around things that you try for your project are also important for the broader community.

Will do. My existing app is working and just needs some refactoring and UI tweaks to be fully usable (if not pretty). I'll see if there's anything I did in there that isn't already covered in the existing examples.

[vasco-santos]

I wonder if it may be possible to just run a go-based relay server via gomobile in the background inside a mobile app and package up the browser-based nodes to point to that gomobile server running locally. The specific use case I've built for is ephemeral connections where the nodes only live as long as the app is open and ideally we don't have any points of centralization since the users will be able to establish the initial connection either via an SMS/QR code and then maintain that connection only as long as is needed. For this particular use case, needing to maintain centralized relay servers doesn't really gain anything over the star server implementation I currently have since all I really want is for peer discovery to be able to happen as flexibly as possible since here again, these are short-lived browser based nodes and the prototypical use case is two friends open the app, generate new nodes with fresh PeerIDs, exchange contact details via QR code, and then go their separate ways and are able to maintain a secure communications path for a limited period of time, burner phone style.

I am not really aware of the state of go-ipfs-mobile. Perhaps I recommend that you start by having it working the the star server and then we can think about other ways of improving that setup.

[acolytec3]

I am not really aware of the state of go-ipfs-mobile. Perhaps I recommend that you start by having it working the the star server and then we can think about other ways of improving that setup.

Okay, as with so many pieces of the implementation details of libp2p, my understanding of star servers is very minimal at the moment so will have to do some research to see if such is feasible or not within the constraints that Android/iOS give. Anyhoo, I'll close this issue so it doesn't clog up the repo and will tag you if/when I find something specific to work on across the libp2p repos.

[david0178418]

Just wanted to thank both @vasco-santos for the information in this ticket and @acolytec3 for asking. I'm new to this IPFS/libp2p stuff and up to my eyeballs trying to do this exact thing with similar questions. I'm realizing that "thar be dragons".