deno
deno copied to clipboard
denoland
WebRTC Integrating
@balupton Is WebRTC not part of the standard browser interface? How would one implement this in userland?
I would check out https://github.com/shinyoshiaki/werift-webrtc. Long term you are going to have a pretty high burden using Google's WebRTC implementation via FFI. Also the security issues that have come with it.
I am happy to help also! If anyone wants to grok WebRTC more I wrote WebRTC for the Curious and work on Pion. Pion isn't relevant at all for deno, but happy to throw in stuff that I learned along the way writing it.
Shouldn't this be in user land?
...
@balupton Is WebRTC not part of the standard browser interface? How would one implement this in userland?
std/ws is a thing so it probably could be user-land, however if it is it should be a std user land since this can be considered a standard interface.
std/ws is a thing
std/ws is a server, not a client. for client we have the web WS API. WebRTC shouldnt be a module, but a built-in.
std/ws is a server, not a client.
Well originally it had both, but I do get and agree with your point.
I actually just dug through the source-code to check and I was under the incorrect assumption that the websocket client was some sort of ts shim that was just auto-included. So that's good to know.
Because we have not made a decision on if this will be implemented or not. feat label is only used for issues that we have decided should be implemented.
Maybe this will be of value one day: https://github.com/webrtc-rs/webrtc
webrtc is now a W3C standard recommendation , please consider integrate at least datachannel via usrsctp which is used by Chrome and almost all the others
@mko-io usrsctp is being replaced with dcnet in Chrome. Might be worth exploring if integrating that is easier!
Hey guys, I assume this is not a priority at all for Deno core ? It would be really nice to have this.
Yes, this isnt a priority. I am keeping an eye on this, and we probably would use the WebRTC crate, but this wont happen anytime soon as there are other priorities
Yes, this isnt a priority. I am keeping an eye on this, and we probably would use the WebRTC crate, but this wont happen anytime soon as there are other priorities
Cool, thanks for answering. I was just asking since webGPU was added, I thought this might be an api that is more "important" since it's already a standard.
You're about to see WebRTC + AV1 replace RTMP + HLS, I think. The big companies are about to WHIP it into shape.
I've tested Cloudflare WebRTC Stream it's much lower latency than RTMP, feels like AV1 + WebRTC is coming.
Imagine being able to play a video from Deno serverside WebRTC (Rasberry Pi) to a Browser, would be spicy! Or open a port from an IP camera without RTSP/RTMP direct to a browser device with sub second latency and no HLS. Double Spicy!
@crowlKats my apologies for tagging you like this, more than 1 year has passed since I asked about some updates. I know if there were updates on this someone would have informed us.
I am asking this again not to sound demanding or rude, but this is such an exciting feature and it would be so cool to have a native way of building SFU's in deno. Were they any internal discussions about the potential inclusion in deno ?
No, there have been no discussions about this, as it is not a priority. Also, the involvement of this project is unknown, but likely quite complex.
Some of the fun of WebRTC is better left out of Deno at the moment...
- https://github.com/w3c/webappsec-csp/issues/92
- https://www.security.org/vpn/webrtc-leak/
There's a webrtc: 'block' CSP in a spec but it hasn't made its way to browsers yet. Deno, not using CSPs, should probably have a similar off switch when this gets implemented. https://wpt.fyi/results/content-security-policy/webrtc?label=experimental&label=master&aligned
Maybe it should always be in userland. That's what I'm thinking. It's a privacy nightmare not just for the reason I mentioned. I gave the lone thumbs up to the comment suggesting this.
Edit: OTOH if Deno started implementing it right now and added new permission(s) for it, maybe that would shine a light on how the browser needs to have ways to control the permissions using Content Security Policies and/or permission policies (currently there is a permission for the media parts of videoconferencing but not the network connectivity of WebRTC). But it would be an unusual thing to use to determine the roadmap...
VPN should be extremely bad for webRTC leak. Such VPNs probably already don't exist because the creators know that people will not pay and use if it has leak and because this leak issue is old and well-known. No one VPN I tested had webRTC leak. Anyway, servers don't use VPN.
WebRTC and related APIs (MediaStreamTrackGenerator(), MediaRecorder()) can be the second reason after Typescript why people might prefer Deno over Node.js. It is weird that it is not a priority.
What's the snag in copying these APIs from Chromium?
Any updates on this , I am more than interested in this topic for one of my projects
I believe WebRTC support is especially important following the recent unveiling of OpenAI's Realtime API, which underlays advanced voice mode in ChatGPT. Lots of us will want to integrate with this new service. Currently, the only path forward seems to be utilizing some kind of intermediate relay such as LiveKit. Alternatively, one could use web sockets, but this isn't as reliable for the use case of audio streaming. I understand that there's likely a long list of other important items following the release of Deno 2 (congratulations btw), but I figured I'd suggest revisiting this one.
I've made a WebRTC library for Node/Bun a while back: https://www.npmjs.com/package/webrtc-polyfill, it seems to work on Deno just fine as well, however I've only ever used it for RTCDataChannel.send, so the MediaStream implementation was never tested, I welcome any contributions.
It is roughly x3.4 quicker than wrtc and ~x1.2 quicker than google's webrtc impl. It is however single-threaded [for the most part]
It uses libdatachannel which is known to take some liberties with how it implements WebRTC, but from my testing it was compatible with any WebRTC consuming library I've tried
