Support for WebRTC transport

[JustinDrake]

So the Duo team (working on OpenBazaar) was all excited that we can now have truly peer-to-peer communications between js-ipfs and go-ipfs using WebSockets. It turns out that, in practice, WebSockets doesn't work direct p2p. The reason is that Firefox (since always) and Chrome (since recently) only allow for wss:// (secure WebSockets) on an https:// page. So the Duo team has to use a wss:// to ws:// proxy, which truly sucks.

Our hope is that go-libp2p will support WebRTC. The Duo team would be happy to review and test the implementation. 👍

[whyrusleeping]

@JustinDrake I would love to have this too. The issue is that there is no decent implementation of webrtc in go (to my knowledge). We definitely want this too.

As an aside, we're adding support for QUIC soon, which should help some (chrome will have support for QUIC, and other browsers should follow)

[JustinDrake]

Crazy idea: could we use a WebRTC-to-WebSockets Node proxy, given that we have WebRTC support in Node?

The issue is that there is no decent implementation of webrtc in go

Cool. Out of curiosity, what is wrong with https://github.com/keroserene/go-webrtc? It seems to be relatively active. Maybe it's worth talking to the team behind it?

we're adding support for QUIC soon

Oh awesome! Is there a PR/branch/issue you can link to?

chrome will have support for QUIC

Do you know when? (I ask because I'm expecting the launch of OpenBazaar 2.0 in a few months.)

[ghost]

So the Duo team has to use a wss:// to ws:// proxy, which truly sucks.

Put nginx in front of the /ws listener, for SSL termination

[ghost]

Put nginx in front of the /ws listener, for SSL termination

What I meant to imply apart from SSL termination, is: I'd strongly advise against running js-ipfs or go-ipfs things directly exposed to the internet. Better put nginx/haproxy/apache in front.

[JustinDrake]

Thanks @lgierth. My colleague @jackkleeman has adapted a Go wss to ws proxy here https://github.com/duomarket/websocketproxy

Using nginx may be more scalable/resilient/well-tested. Do you happen to have an nginx config file readily available for SSL termination?

I'd strongly advise against running js-ipfs or go-ipfs things directly exposed to the internet

Is that for security reasons? https://github.com/OpenBazaar/openbazaar-go is running go-ipfs without anything in front.

[jackkleeman]

@whyrusleeping I believe https://github.com/keroserene/go-webrtc uses the same underlying native code as the node library we're using in the js webrtc transport - does this make it a good option? It seems their api is not finalised, but surely the underlying functionality will be similar

[whyrusleeping]

@jackkleeman Yeah, We can start putting something together with that and see how it goes. No current guarantees on a timeline, i'm more than normally busy for the next two weeks. If anyone else wants to take a stab at it though, i'll be around to provide guidance

[Sean-Der]

Hey @whyrusleeping I am working on pions-webrtc it is Go native webrtc (does not use libwebrtc at all) we are maybe two weeks away from DataChannels being done. I am actively using it for send/recv of audio and video currently.

We have 4 active contributors, and moving decently quick! Would love to see if I can help get it into go-libp2p and figure out the things needed to make it work.

(I am 100% biased on this) the issue with keroserne/go-webrtc is that it uses libwebrtc, so not very portable and your throwing away all the benefits of Go by using it. But that could totally work as well!

[Stebalien]

A pure-go library would be awesome. We currently don't have any C code and I'd like to keep it that way. Take a look at https://github.com/libp2p/go-ws-transport/ for a good example transport. Once it's ready, we can help on the implementation.

[whyrusleeping]

@Sean-Der Thats awesome! I'm super excited, and we're here to help!

[daviddias]

@Sean-Der That's rad! ⚡️⚡️⚡️

What's the usecase you are creating it for? It would be excellent if the multiple pieces of WebRTC were modular enough so that we could remix them (DTLS, Hole Punching / SDP generation, etc). Is there an architecture or interfaces doc that I should look at?

[Sean-Der]

Thanks for all the positive feedback, that is awesome :)

---

@Stebalien ACK! Currently DTLS uses Cgo for OpenSSL, but will be doing that after DataChannels are complete. There are lots of existing implementations, but they aren't complete in different ways hopefully I can work with one of them to get it where I need it. Everything else is Go though! (RTP, SRTP, SCTP, ICE, Video/Audio packetizers) were the big ones for me.

---

@whyrusleeping awesome, thank you :) the feedback once you start using it will be huge for us!

Code wise if you know anyone who is interested in DTLS or ICE that would be great. DTLS is in C now, and ICE is just ice-lite not full yet. I have plans to do both though! But won't complain if someone who actually knows what they are doing does them faster then me :)

---

@diasdavid Originally I was going to use it to send video dynamically created on a server (via GStreamer) to a browser. I found libwebrtc difficult to build and use, and other versions of WebRTC lack important things (poor jitterbuffer implementations) and had stability issues, so we decided to give it a shot!

After I announced it most people were interested in DataChannels, so that just became the priority. My only goal now is to get people using/testing it so it can be better. WebRTC has a lot of potential, but is held back by ease of use. I think another wave of interesting things could be built if it gets easier for backend developers. Once it works in Go I also want to generate bindings for other languages, the safety of Go but C bindings could be really exciting. Opens it up for Python/node.js etc...

I would love to break things out into separate packages! I have them in internal right now so we can just do one commit/move quickly. But once they are stable I am all for making SCTP/SRTP/DTLS/ICE public usable packages (and anything else people want)

The only thing I have right now is our roadmap I can do an architecture or interfaces doc also! I would love to do anything you think that will help it be successful. Things are very informal, so open to anything!

[Sean-Der]

@Stebalien @whyrusleeping @diasdavid Good news, DataChannels landed! I have an example here

Two caveats though.

• We only support ice-lite (Browser <-> pion-WebRTC works great, but pion-WebRTC <-> pion-WebRTC isn't supported yet)

• We use OpenSSL for DTLS

I plan on implementing both, but just pushed DataChannels out so I could get things rolling :) what is the best next steps? Do we have to get these two things done before we move forward, could we start things and just get a PoC/rough demo?

Who should I talk to/work with on making this happen? I am happy to do all the coding/design!

---

Also totally happy to tweeze out anything useful we built to share with other people! I just don't want to add the extra burden of vendoring etc.. if the libraries aren't even useful for other people.

[whyrusleeping]

Hey @Sean-Der, thats great to hear!

If you want to help out with the libp2p integration, the first thing to do would be to implement the libp2p transport interface using webrtc. That interface lives here: https://github.com/libp2p/go-libp2p-transport

We recently implemented a QUIC transport here that you can look at as a bit of a reference. This was written by @marten-seemann, who is probably open to answering any questions about implementing transports you might have.

Then, you'll want to chat with @diasdavid (or maybe @vasco-santos ) on the javascript libp2p team, as they maintain these two things on the javascript side:

• https://github.com/libp2p/js-libp2p-webrtc-direct
• https://github.com/libp2p/js-libp2p-webrtc-star

Unclear how exactly we want to go about this, so I would make sure to ping them to ensure that we have interop.

[backkem]

Hi all, I hacked together a PoC webrtc-direct transport on top of pions/webrtc. You can find it at backkem/go-libp2p-webrtc-direct. Right now it's purpose is mostly to gather some experience building things on top of pions/webrtc. We'll probably start chipping away at the go DTLS implementation soon. After that I hope to find the time to get the transport in a better shape.

[backkem]

Quick update on pions/webrtc:

• We just released v1.2.0. Starting from this version the whole WebRTC stack is now written in Go and is fully go-gettable.
• We built our DTLS implementation out of tree.
• After the release we've also split off our SCTP and Data Channel implementations into their own repositories.

[backkem]

I rewrote my Go webrtc-direct transport at backkem/go-libp2p-webrtc-direct to better fit the go transport interface and improve error handling. I added an example under /examples to show off compatibility with js-libp2p-webrtc-direct.

I would like to try plugging it into libp2p (and even ipfs) but i'll have to figure out how to build those first.

[whyrusleeping]

@backkem Thats awesome! I think the first step to getting this integrated into libp2p would be to write a transport for it, that just looks like filling out the interface like this: https://github.com/libp2p/go-tcp-transport

Then it plugs into the libp2p constructor. cc @Stebalien and @raulk for more details.

Also cc @daviddias who will be super excited to hear about this :D

[backkem]

@whyrusleeping Thanks for the feedback. The library already implements the transport interface. So it seems I need to figure out the libp2p constructor configuration and build process. There are also still some open questions around dependency management. However, I noticed this is a hot topic with go modules support being added.

[whyrusleeping]

@backkem oh whoops. I somehow missed that your links were already libp2p transports, sorry about that. This is really cool!

Heres a quick example that shows how to run a libp2p node: https://github.com/libp2p/go-libp2p-examples/blob/master/echo/main.go

To add a transport, you'll want to create your transport, then give it to the libp2p constructor via this option: https://github.com/libp2p/go-libp2p/blob/master/options.go#L122

As for dependency management, everything should work fine without vendoring, but when we get to plugging it into ipfs, the dependencies used by the transport will need to match the ones used in go-ipfs. @Stebalien who is out until early next week can advise more there

[backkem]

Thanks for the nudge @whyrusleeping. I was able to create the equivalent of the echo example. I'll look into adding a matching JS example as well. That should give even more insight into their compatibility.

Let me know if there is any interest in incubating this transport. It should be fairly straightforward to turn this into a js-libp2p-webrtc-star port, a.k.a. go-libp2p-webrtc-star, as well.

[raulk]

@backkem this is awesome! Thanks for the contribution. I'm taking a look now and getting up to speed. I'll help you land this inside the libp2p org/universe. I'll update shortly with next steps.

[backkem]

Great, looking forward @raulk. Feel free to ticket out anything that needs addressing in the repo.

[Sean-Der]

Hey @raulk anything we can do to help :)

I am really excited to make this happen, it has been a goal of ours for a while!

[backkem]

Fun little update: go-libp2p-webrtc-direct now has initial support for WASM: demo. This allows you to use the transport from the browser or Node.js. This may open some new doors for go-libp2p.

[raulk]

I was reviewing historical issues and I wanted to close the loop on this one. The go-libp2p-webrtc-direct transport is now part of the libp2p org! https://github.com/libp2p/go-libp2p-webrtc-direct

IUC, this transport, along with its js equivalent, provide for direct WebRTC connection server-browser. Correct?

[backkem]

This transport is able to set up a WebRTC connection between Go and JS, therefore enabling native to browser (p2p) communication. I think the 'direct' part of the transport name refers to the direct http connection used for signaling. A better signaling strategy can further decentralize the transport. E.g.: On the JS side you have the WebRTC-star signaling approach and there is an ongoing discussion about abstracting signaling from the transport itself.

[mtojek]

Hi all,
I've just finished go-libp2p-webrtc-star. It passes streaming tests defined in the transport utils suite. WebRTC part is developed based on @backkem 's go-libp2p-webrtc-direct.

Cheers!

/cc @JustinDrake @whyrusleeping @raulk

[raulk]

@mtojek fantastic work! Is this something you’d like to contribute to the libp2p org, so that it’s easily discoverable?

[mtojek]

@raulk Thank you for your kind words!

Absolutely! If you consider moving the project under libp2p org, then I don't see anything against.

[shazow]

Is this issue officially done? 😍 I believe @mtojek has to initiate the project transfer to the libp2p org, in the Settings -> Danger Zone section.

[mtojek]

Sure, why not - I can do this ;) Just need a confirmation from the org owners.

[backkem]

Just noticed very promising WebRTC transport being built: go-webrtc-aside-transport

[aarshkshah1992]

@mtojek

What's the status of https://github.com/mtojek/go-libp2p-webrtc-star? Can we deem it to be production ready ? If not, please can you tell us what remains to be done ?

[mtojek]

Hm.. last time I used it was a month ago. I suppose you need to reverify the compatibility against latest libp2p API and star servers.

[aarshkshah1992]

@mtojek What are these STAR servers that you speak of ?

[aarshkshah1992]

Closing this in favour of #1018 as this has accumulated a lot of history.