Having to run your own TURN server is a notorious barrier for building serious p2p apps so I really welcome this development!
Not libraries - we’re building APIs that allow you to create rooms/channels, connect participants, manage authn/authz, ingest via non-WebRTC protocols (and still broadcast to participants), and trigger serverless code based on events in those channels.
Those clients will still connect over WebRTC using any browser, native client, or client abstractions you build - one of the best things about WebRTC are its browser APIs and existing set of clients.
In the meantime, we’re launching a “managed TURN” service for teams who already have WebRTC infrastructure but who need help scaling and securing.
(I work at Cloudflare and co-authored the blog)
500ms?
Am I missing some key information in the context of WebRTC? Or something inherent of TURN ( Traversal Using Relays Around NAT ) ?
But it is interesting they are basically taking all the pain of building a web / internet Real Time communication system with open standards so I presume anyone could incorporate into their apps instead of getting lock in by third party solution.
TURN (as a protocol) doesn’t change this on its own, but our network backbone is going to help minimize jitter and keep latency as close to optimal as possible.
I would agree (if this is your implication) that this is very different from what we consider “real time” when it comes to control systems and safety systems.
(I’m a co-author of the blog post)
We also have WebSockets via Cloudflare Workers for layering more complex logic on top: https://developers.cloudflare.com/workers/learning/using-web...