Yes. We're building our own voice and video system in Rust, with our own voice server and our own call code in every Fluxer app. It will replace LiveKit, the voice and video software that Fluxer calls use today. It's item 2 on our 2026 roadmap, we plan to ship it in 2026, and every call on the new system will be end-to-end encrypted.
What changes with the new voice system?
The desktop, web and mobile apps will all move to the new system.
- Every call will be end-to-end encrypted, with no setting to turn it off and no unencrypted fallback. Calls on today's system aren't end-to-end encrypted.
- Audio and video will travel over QUIC in place of WebRTC. The new system recovers lost packets and adjusts to your connection, and joining a call will be faster.
- Each stream will get its own connection, and a problem with one stream is less likely to affect the rest of the call. A stream can also have far more viewers.
- The desktop app will encode and decode video on your graphics card on Windows, macOS and Linux where it can, and use several CPU threads when it can't.
- Speech will hold up better on connections that lose packets.
- Self-hosted instances without a voice server will be able to run peer-to-peer calls in the desktop app, with relays they run themselves or no relays at all.
Why is Fluxer building its own voice system?
With our own voice system, we'll rely less on how each browser and platform handles WebRTC, with all its quirks, and the code for calls is simpler for us to maintain. We'll also be able to see what's happening at every step of joining a call.
Today, Fluxer runs calls on a LiveKit server, and the apps use WebRTC, which is the call technology built into the browser engine. The new system has a voice server that we built ourselves in place of the LiveKit server, and the apps get our own call code in place of WebRTC. For years, Discord's native apps have used their own signalling and encryption over plain UDP, and only Discord's browser app uses WebRTC.
The gateway is the part of Fluxer that keeps your apps up to date in real time, and on the new system it tells the voice servers directly who is in which call. That stops the mismatches we had when we kept that information in sync with LiveKit.
How will calls connect without WebRTC?
Audio and video will be sent as RTP packets over QUIC, a modern internet transport, and QUIC also encrypts the connection from the app to the voice server. Audio and video go in QUIC datagrams, which don't wait for lost packets, and that keeps the delay low. Keyframes, the full video frames that the following frames build on, go over reliable QUIC streams.
When packets get lost, the new system can send them again or fill the gap with redundant data. It also adjusts the bitrate to what your connection can handle.
Will the new voice system work in my browser?
Yes, if your browser is recent enough to have two features the web app needs. The WebTransport API gives the app QUIC streams and unreliable datagrams over HTTP/3, and the WebCodecs API gives it direct access to audio and video codecs.
A browser needs to support both to join a call on the new system, and browsers without them can't join. The browser and the desktop app share Rust code for packetising video, checking codecs and running DAVE, the encryption protocol for calls. It runs through WebAssembly in the browser and natively in the desktop app.
Will the new voice system improve screen sharing?
Yes. Streams will be separate from calls, and each stream will get its own connection and its own process on the voice server. A problem with one stream is less likely to affect the rest of the call, and a stream can have far more viewers without slowing the call down.
The new system replaces the encoding path behind the choppy screen shares some people see today. Without a hardware encoder, today's system can fall back to a single-threaded software H.264 encoder, which is a known cause of choppy screen shares.
How will video encoding work on the new voice system?
The desktop app will encode video on your graphics card where it can. It uses NVIDIA (NVENC), AMD (AMF) and Intel (QSV) encoders on Windows, NVENC or VAAPI on Linux and Apple's VideoToolbox on macOS. Decoding uses your graphics hardware too, and without a hardware encoder, the software encoder uses several CPU threads.
When you share your screen on Windows or macOS, each frame stays on the graphics card from capture to encoder, and on Linux it does when PipeWire hands frames directly to the encoder. The app uses Windows Graphics Capture with Direct3D 11 on Windows, ScreenCaptureKit with VideoToolbox on macOS and PipeWire on Linux.
Video from other people is drawn with your operating system's own graphics APIs and not inside the browser engine, with Direct3D 11 on Windows, Metal on macOS and EGL on Linux with X11. Both of these mean less copying of video frames and less work for your CPU. The new system supports the H.264, H.265, AV1, VP8 and VP9 video codecs.
Will voice sound better on a bad connection?
Speech will hold up better on connections that lose packets. Voice uses the Opus codec with forward error correction, which sends a little extra data in each packet, and with DRED, which uses deep learning to recover speech from packets that never arrived.
The desktop app keeps only one part of WebRTC, its audio processing module, and uses it for echo cancellation, automatic gain control and a high-pass filter that removes low rumble. Noise suppression is our own and uses RNNoise and DeepFilterNet.
Will calls on the new voice system be end-to-end encrypted?
Yes. Every call on it will be end-to-end encrypted with DAVE, an open protocol from Discord that's built on the MLS standard. It protects your microphone audio, camera video, screen share and screen share audio, with no setting to turn it off and no unencrypted fallback. You'll be able to compare a verification code with the other people in the call.
Will the new voice system support peer-to-peer calls?
Yes, for self-hosted instances. An instance without a voice server will be able to run its calls peer-to-peer in the desktop app, connected through Iroh. The instance can run its own relays for people who can't connect directly, or run no relays at all.
The mode applies to all calls on the instance, and browsers can't join peer-to-peer calls. Peer-to-peer calls on the new system are end-to-end encrypted too. On today's system, fluxer.com has separate peer-to-peer calls that it's turning on country by country.
What changes for people who self-host Fluxer?
To add a voice server to your instance, you'll only need to give it a registration token during setup, and your instance will pick up the server automatically. The admin panel will show each server's health and load, and calls won't go to an unhealthy voice server.
In our benchmarks, the new voice server is faster and uses less memory than our LiveKit setup. It can also share bandwidth and server capacity fairly between users, which keeps CPU usage predictable and makes voice servers easier to plan and scale.
Will the new voice system fix the problems people reported?
We listed the voice, video and screen share problems from Fluxer Feedback that the new system fixes, including the ones we'll fix before the new system ships.
When is the new voice system coming?
It's in development, and we plan to ship it sometime in 2026. Around March 2026 we said encrypted calls would come in the next update, and that estimate was too early.