Explanation of WebRTC roadmap

[transitive-bullshit]

I'm not clear on how exactly the WebRTC version of webtorrent will interface with the existing browserifiable libraries bittorrent-client/swarm/protocol.

I think progress towards the actual web portion of webtorrent would benefit greatly from a detailed breakdown of the plan to build the webrtc version based on what exists today, including:

• what modules need to be built and their anticipated dependencies
• how the actual peer connection / communication will be handled over webrtc
• the expected browserify process
• will any existing webrtc modules be used for connecting the hybrid bittorrent/webtorrent clients with the webtorrent clients? e.g., wrtc, webrtc, or webrtc.io?

Thanks! 👍

[feross]

I have lots of notes about how the WebRTC part of WebTorrent will work in a notebook with lots of pictures, but I haven't written them up electronically yet. I think it would be awesome to meet up with you in person to be more efficient and figure out the parts that are still not 100% clear. Or maybe IRC on #webtorrent is enough.

I think bittorrent-protocol can be used as-is on the web. It's browserifiable, transport agnostic, and it has an extension API (that we can expand if necessary) so we can support new message types to make p2p webrtc signaling work.

There may be some way to generalize bittorrent-swarm and bittorrent-client so they're more transport agnostic, but it's less obvious how. When I was working on the webtorrent chrome app I wrote chrome-net and chrome-dgram which match the node net and dgram APIs exactly but call the underlying chrome.* APIs under the hood. So they can just be swapped in for the built-in node modules using the browser field in package.json and browserify. I don't think it will be quite so easy -- it's probably impossible -- to write a shim that uses webrtc under the hood since it has such a different model of connecting.

I think that the best we can do is figure out some way to generalize it so more code can be shared and we don't need to write a webtorrent-swarm and webtorrent-client module. Though I expect that that will probably be easier to do in the short term, but create more a maintenance burden in the long-run. The two clients might be different enough that it's worth splitting them up.

This is a picture of the dependencies that I made for a presentation.

Stuff in red hasn't been implemented yet. But the webtorrent side is definitely missing some deps that will need to be written.

[transitive-bullshit]

Thanks for the thorough breakdown. I'd love to meet up in person and brainstorm / spec out the remaining design, but I don't expect to be in Cali anytime soon :-/

I agree that it'd be great if we could just swap out webrtc driven versions of net and dgram, but I hear you that it's probably not that straightforward.

I'm particularly concerned about the hybrid webtorrent clients; if we can design a transport-agnostic way of connecting to webrtc-based peers and normal bittorrent peers in a seamless way, I think we'd be well on our way there.

I think some transport abstraction like the one used by discover could work. We could have bittorrent-transport, bittorrent-transport-node, and bittorrent-transport-web. bittorrent-swarm would need major refactoring to utilize a transport pool and associate a particular type of transport with each peer. bittorrent-dht, bittorrent-tracker, and bittorrent-client would all need to be updated to be transport agnostic as well.

If you think this transport abstraction approach is reasonable, maybe we can come up with a rough draft of what its interface would look like?

[feross]

We have support for WebRTC peers now, so I'm going to close this issue.