We Just Released our Rust WebTransport Teleconferencing System - Here are Some Lessons Learned

Hello everyone,

We're thrilled to announce the release of our new Rust WebTransport teleconferencing system! This system allows you to have teleconference calls without having to disclose your personal data to 3rd parties.

Our value proposition is simple: a web first video conferencing using bleeding edge browser technologies: WASM, WebCodecs, WebTransport with a very simple protocol written like it is 2023 :smile:

We only support Chromium/Chrome/Edge Desktop for now because our system needs WebCodecs, WebTransport support.

The system is available today at Rustlemania

We will NEVER share data with 3rd parties, unlike zoom which admitted cutting off activists' accounts in obedience to China

Best of all? Our system is 100% open-source! Unlike services like nginx that keep "the good stuff" for paid versions, we believe in the power of open-source and make all our work available on GitHub. You can check out our codebase here.

Overcoming Challenges

We encountered quite a few hurdles on our journey. For one, we had to build our own yew-webtransport and yew-websocket integration from scratch by adding WebTransport definitions to wasm-bindgen (pull request link). We also had to add WebTransport support to the h3 crate (pull request link). co-created by @ten3roberts

We created our own h3 fork that is actively maintained and has support for Web Transport sec-http3

Furthermore, learning how to host UDP services on k8s clusters, define new UDP load balancers, and navigate the health checks was a steep learning curve, especially since nginx ingress doesn't support UDP or HTTP3. However, as of June 1, 2023, nginx seems to be on the brink of supporting HTTP3, they just merged the http3 branch back into baseline https://github.com/nginx-quic/nginx-quic

A significant realization was understanding the value of TCP's predictable packet order for streaming. With QUIC, the responsibility of keeping things in order falls on us, and it's not a simple task.

Why Rust and WebTransport?

We chose Rust for its type and memory safety and performance. Rust, coupled with the WebTransport technology, is expected to deliver lower latency than other teleconferencing systems, allowing us to adjust the bitrate of streams even under internet connections with severe constraints (we are still working on this).

WebTransport uses QUIC, which, while still using ACKs, handles them more efficiently. It assigns unique numbers to each data packet, enabling independent acknowledgment of packets. This feature becomes invaluable in scenarios where packet loss is likely, providing reliable data transmission.

To enable webtransport you need to pass a feature flag to the url:


Special Thanks

Special shout-out to @ronen and @leon3s for their invaluable contributions, particularly their work on refactoring the monolithic components into a proper MVVM architecture.

The Future is Bright

Looking ahead, we have big plans for this system. We intend to enhance screen sharing by improving resolution, and we're working to enable all devices and people to use our teleconferencing system - with the goal of becoming the standard for IoT real-time audio and video streaming. Imagine moving your real-time Arlo streaming system to use our protocol - the possibilities are endless!

We look forward to further polishing and tweaking the system in the foreseeable future, and we can't wait to see where this journey takes us.

Stay tuned and feel free to check out our work. We welcome feedback and contributions from the community. Let's make this system the best it can be, together!


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.