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.)

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

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.