WebRTC data channel support

[AdrianRossouw]

Over at jschan we are busy discussing allowing peer-to-peer connections via webRTC.
GraftJS/jschan#27

We're currently planning to do this the same way we did the websocket support (#56), with a custom transport, because re-implementing SPDY is just too big a task for us right now.

[dmcgowan]

There has already been some discussion over this for libchan in general in #21. Currently there are no plans to expand the official protocol to support a wire protocol other than SPDY. I will advocate for QUIC when there is a standard and golang implementation. Any webrtc transport could be achieved on top of the golang implementation using SPDY, same with js with the obvious additional work to get a more flexible SPDY library. I would advice any changes to the official protocol (including non-spdy wire protocols) to be document and we can allude to it in the README. I think I am going to close this as a duplicate of #21 unless there is another specific change request that doesn't apply.

[AdrianRossouw]

while I agree that the SPDY approach is definitely technically attractive, I just wanted to remind you about this bit from the readme.

An explicit goal of libchan is simplicity of implementation and clarity of spec. Porting it to any language should be as effortless as humanly possible.

While jschan will eventually get to that point, I don't think that building a self-hosted implementation of SPDY could be characterised as effortless for most projects. I don't even know if python has an implementation that could work. PHP probably never will (due to it's nature).

If the goal is really to have implementations of libchan in all the major languages, and have that be the preferred (only?) way to speak to docker ... timelines should be clearly communicated and adjusted to take into account the years it will likely take for the SPDY ecosystems to evolve in all the languages.

ping @mcollina @shykes.

---

Feel free to close this issue btw. I kind of have this habit of leaving ideas/specs in issue queues to provide future collaborators with opportunities to contribute.

I think github's social cues around emphasising on open closed issue counts make that less than ideal though.

[AdrianRossouw]

I re-read that last comment after posting it, and the tone was far more aggressive than I had intended. This isn't a crisis, or a major roadblock or anything, I just wanted to point out the disconnect.

[dmcgowan]

Agreed about ease of implementation, SPDY isn't the easiest protocol to implement. The attraction of SPDY is more that there is a defined standard and it has been proven effective. I should have put more of an emphasis in my original statement on my request for documentation on any additional protocol that is added, so there can be an independent discussion about it. We are not looking to define a wire protocol, but may be willing to consider one that is defined, implemented, and used elsewhere. My intent for closing was not hostility toward your idea, just looking for ways to keep the ideas organized to avoid duplication. I think there may be some independent ideas here from the other issue that perhaps is not reflected in the title alone, ideally suggested ideas eventually get turned into proposals as described in the contribution guidelines. Right now the number of issues on this project is manageable so I will keep it open, if you see any duplication feel free to self-manage or link to related issues.

[mcollina]

Part of this is my fault. I wanted jschan to work in the Browser and I took the easiest possible path that could work, and never did the proposal part. I'll try to remedy that in the future, but it takes some time.

[pkieltyka]

first you need a webrtc data channel implementation in Go ... no? I'm not aware of any, I've looked before and even considered implementing it

[backkem]

I know this is a rather old ticket but there is now a native Go WebRTC implementation over at pion/webrtc.