Last year, we introduced the DAVE protocol as our solution to bring end-to-end encryption ("E2EE" for short) to Discord's audio and video calls. Since then, DAVE has been providing E2EE for tens of millions of calls on Discord every single day. Today, we're excited to announce that we're bringing DAVE support to all our remaining platforms, including browsers, consoles and our Social SDK.
Starting March 1st 2026, clients and apps without DAVE support will no longer be able to participate in Discord calls. This will complete our transition from last year’s experimental rollout to making DAVE the standard for Discord voice and video calls.
In this article, we'll explore the technical challenges and tradeoffs we encountered while integrating DAVE with web browsers, from WebAssembly performance considerations to Web Worker architecture decisions. We'll also share more about our timeline for deprecating non-E2EE calls and what you may need to do to make sure you or your application can still connect to voice channels come March 1st 2026.
The Technical Challenges of Browser Support
From the very beginning, we designed DAVE with web browsers in mind, ensuring it could support the same breadth of video codecs as our other platforms. Planning this from the outset would ensure a better video call experience, as modern devices deliver excellent hardware support for codecs like H.265 and AV1 giving users better video quality and more efficient bandwidth utilization.
The Encoded Transform API
As mentioned in our previous blog post, using the WebRTC Encoded Transform API was a crucial choice to support DAVE on web browsers.
In essence, this API allows us to perform end-to-end encryption of audio and video data inside the WebRTC pipeline.
While adding support for the WebRTC Encoded Transform API across browsers, we encountered an unexpected challenge with Firefox. The initial proof-of-concept worked well and DAVE’s encryption functioned as expected in controlled tests. However, when we tried using DAVE in real Discord calls, it stopped working. The Web Worker responsible for encryption wasn't receiving any data from the WebRTC Encoded Transforms API.
After extensive debugging through our application stack didn’t resolve the issue, we decided to build Firefox from source to investigate at the browser level. That’s when we discovered a small edge case: the FrameTransformerProxy that is backing RTCRtpScriptTransform in Firefox could become deadlocked when video data was fed to the transformer too early. The video data was stored for deferred processing, which happens under a mutex accessed again by the transform operation causing a recursive deadlock.
We were very impressed with Mozilla's responsiveness throughout this process. Building and navigating the Firefox codebase proved surprisingly straightforward, and the entire process - from downloading the repository to submitting our patch - took just over a day. Mozilla quickly responded to our submission, and after a few rounds of implementation tweaks, the patch was merged! These fixes are now available in Firefox v142.0, which will be the minimum version required to use DAVE on Firefox.
Leveraging Web Workers for Encryption
Each Discord connection uses a dedicated Web Worker to handle encryption and decryption of media streams before handing it back to the web browser that will perform the encoding or decoding. For Discord calls, one worker handles encryption and decryption of the audio and camera video for the call, while separate workers handle the same for the stream’s audio and video for associated screenshare and game streams.
Each WebRTC audio and video stream has a unique SSRC (Synchronization Source identifier) that is transmitted with every frame. With DAVE, we use this SSRC to identify which symmetric encryption key to use for each frame. Each Web Worker maintains only the necessary context about the call: incoming and outgoing audio and video data, a mapping of SSRCs to User IDs, and the encryption keys for each user. This design keeps the worker lightweight and focused solely on the cryptographic operations.
The JavaScript main thread manages the WebRTC connection, tracking which users are in the call and their different media tracks. The main thread also handles the Messaging Layer Security (MLS) negotiation when users join or leave calls. This separation is crucial for performance, as MLS group changes can proceed immediately without requiring round-trip to the worker which may need to finish encrypting a frame first, thus minimizing latency during member joins and leaves.
Whenever a change occurs to the MLS session, such as a user joining or leaving the call, the main thread sends a message to the worker to update its cryptographic state. This asynchronous approach ensures that encryption operations continue smoothly while group membership changes are processed.
Reusing Proven Code with WebAssembly
Our DAVE implementation has been battle-tested across Discord's entire ecosystem, processing billions of encrypted calls on both desktop and mobile. By compiling this same C++ codebase to WebAssembly, we eliminate the risk of platform-specific bugs that could compromise security or performance. This isn't just about code reuse, it’s about deploying cryptographic logic that has already proven its reliability under the massive scale of Discord's daily usage.
The encryption process requires careful considerations to leave the metadata required by the WebRTC packetizer unencrypted. Once the data leaves the encryptor, it cannot be modified in any way before it reaches the decryptor or the decryption will fail. For that to be possible, the encryptor needs to output data that will go through the WebRTC packetizer, Selective Forwarding Unit and WebRTC depacketizer untouched.
This byte-level parsing and selective encryption is computationally intensive and error-prone to implement. WebAssembly gives us near-native performance for these operations while avoiding the complexity and potential bugs of reimplementing this logic in JavaScript.
Performance Trade-offs: WebAssembly vs. SubtleCrypto
While WebAssembly brings significant advantages for frame parsing, we do pay a minimal performance cost for cryptographic operations compared to native browser APIs like SubtleCrypto. However, our benchmarking revealed surprising nuances in these trade-offs:
-----------------------------------------------------
Benchmark Time Iterations
-----------------------------------------------------
DaveWasm/256 3 us 305400
DaveWasm/1024 10 us 99000
DaveWasm/8192 74 us 13600
DaveWasm/16384 146 us 6900
SubtleCrypto/256 4 us 236100
SubtleCrypto/1024 6 us 155500
SubtleCrypto/8192 25 us 39700
SubtleCrypto/16384 46 us 21900
Audio encryption was 28% faster than SubtleCrypto. Audio frames are typically small in size (usually around ~150 bytes), and the overhead for calling into SubtleCrypto's async APIs exceeds the performance benefits of hardware acceleration.
Conversely, video encryption performance was 192% slower than SubtleCrypto. Larger video frames, often between 2KB - 8KB, saw significant benefits thanks to the hardware-accelerated AES instructions available through SubtleCrypto.
Why WebAssembly Was the Right Choice for Us
Despite the video encryption penalty, WebAssembly provides the optimal solution for Discord's mixed workloads:
Lower Audio Latency: WASM's 28% performance advantage for audio directly translates to reduced processing delays, crucial for maintaining Discord's real-time audio quality
Unified Architecture: Managing the entire transformation in the same execution context eliminates expensive boundary crossings between JavaScript and native APIs
Codec Compatibility: The complex parsing logic would be difficult and error-prone to implement efficiently in JavaScript
Future Improvements: The existence of SharedArrayBuffer memory for WASM opens the door for calling SubtleCrypto directly from WASM in the future which would give us the best of both worlds
Security Audit
Following our previous collaboration with Trail of Bits on the original design review and implementation review of the DAVE protocol, we contracted with them again to audit the new changes to DAVE as well as the new web browser integration. You can see the results of their latest audit here.
Our Bug Bounty program also still includes monetary rewards for successful vulnerability reports related to the DAVE protocol.
DAVE for Consoles, Discord Social SDK, and Stages
Xbox support for DAVE has already begun and will be gradually enabled over the next few months. Your next Discord call on your Xbox One or Xbox Series S|X console may be end-to-end encrypted!
PlayStation support for DAVE will be gradually enabled after their next system update.
The Discord Social SDK comes with built-in DAVE support, so developers don’t need to do anything extra.
Stage channels are a unique environment on Discord where a small number of users “broadcast” to a large number of users. As they are more public in nature and use a different architecture built for scaling to large numbers of participants, they continue to use transport encryption between the client and server but will not be end-to-end encrypted.
Deprecating Non-E2EE Calls
We started work on end-to-end encryption for Discord over two years ago to enhance our user privacy and security. With DAVE now supported across all platforms, we’re very close to making every call fully end-to-end encrypted.
To support our long-term privacy goals, we will only support E2EE calls starting on March 1st, 2026 for all audio and video conversations in direct messages (DMs), group messages (GDMs), voice channels, and Go Live streams on Discord. After that date, any client or application not updated for DAVE support will no longer be able to participate in Discord calls.
This timeline gives users time to install the latest Discord client, which will help ensure full DAVE compatibility and a smooth transition to our E2EE infrastructure. If you regularly close or restart your app, you’re likely already set.
We're committed to making this transition as smooth as possible while delivering the enhanced privacy and security that DAVE provides to all Discord users.
Nameplates_BlogBanner_AB_FINAL_V1.png)
_Blog_Banner_Static_Final_1800x720.png)
_MKT_01_Blog%20Banner_Full.jpg)
.png)
.png)
