RTCDataChannel access and direct access to WebRTC peer contexts

[catapart]

Questions: Is it exposed through the API, or possible at all, to get a reference to the actual WebRTC peer object which webtorrent is using for the P2P connection? If so, would I be able to add data or stream channels that would be forwarded to the client peer?

I would like to be able to use WebTorrent as a replacement for a "signaling server". So webtorrent establishes peers through a simple announcement torrent file, and then my client app can add data channels or media stream channels directly to the active WebRTC peer object, in the browser client.

My concerns are that WebTorrent uses a signaling server, itself, for browser client peers, in which case I would just be deferring complexity to the WebTorrent library instead of replacing it; or that WebTorrent's peer connections don't directly connect two peers together...somehow? Like it broadcasts and receives on different RTC objects, so while to torrent is P2P, the RTC objects aren't? I'm just imagining issues, based on a very limited practical understanding, so forgive me.

Anyway, I expect that this isn't possible, but I really hope that it is! It would be really handy to have a 100% pure p2p client-peer session that you could send arbitrary data and media streams through.

[SilentBot1]

Hi there,

Is it exposed through the API, or possible at all, to get a reference to the actual WebRTC peer object which webtorrent is using for the P2P connection? If so, would I be able to add data or stream channels that would be forwarded to the client peer?

You can either register a bittorrent-protocol extension which would allow you to exchange arbitrary data between connected WebTorrent peers, or in theory you can access the underlaying simple-peer connection, but may possible cause issues with the wire (though my understanding may be wrong on this part), but as explained below, this would be after the peers have already connected via a signalling server.

I would like to be able to use WebTorrent as a replacement for a "signaling server". So webtorrent establishes peers through a simple announcement torrent file, and then my client app can add data channels or media stream channels directly to the active WebRTC peer object, in the browser client.

WebTorrent uses WebRTC (via the simple-peer library) for peer-to-peer communication - this relies on the underlaying signalling servers for this WebRTC connection to be formed by exchanging WebRTC offers and WebRTC answers.

WebRTC offers are short lived, so attaching them to a torrent and sharing this with another peer via some other means during this short lived lifecycle, and then rotating them when the offers have expired, sounds simply like re-implementing the WebTorrent signalling server, though please correct me if my understanding of your goal is wrong?

[catapart]

Okay, gotcha! Yeah, that's what I figured. No true peer-to-peer across the open internet.

Thanks for the quick response! I'll keep looking into what it takes to build a TURN server.