A bug-fix release covering two reports: the direct-message auto-mod setting that was not doing anything, and a set of screen-sharing problems.
The direct message setting was not real (#5483)
3.42.0 added a "check direct messages" toggle to Auto-Mod. It did nothing, and @birdcrazy worked out why: DMs are end-to-end encrypted, so what reaches the server is ciphertext. There are no links in it to find. The setting sat there implying a protection that could not exist.
The check now runs in the recipient's app, after it decrypts the message and before anything on screen is clickable. A link to a domain you have not allowed is shown as plain text with a warning instead of a working link, and images from those domains are replaced with a click-to-load placeholder. Whoever sent it gets told before the message goes out, so nobody is left wondering why theirs arrived greyed out.
The rules that decide all this now live in a single file that both the server and the browser load. That matters more than it sounds: if the two ever disagreed about where a link actually points, the client-side check would become a false reassurance rather than a protection.
Being straight about the limits, since this is a security feature and overstating it helps nobody:
- This is a deterrent, not a guarantee. Anything that can decrypt a DM can also choose to render it however it likes. Someone running a modified client can ignore all of it.
- It protects the person receiving the message, which is the one that counts. A sender can skip the check on their own machine, but they cannot switch off the one running in your browser.
- Other Haven clients need the same check before the story is complete. @birdcrazy raised the Android app specifically and that is a fair point.
Images in DMs were already covered by the image proxy added in 3.43.0, and link previews in DMs already went through the server's domain policy. This closes the remaining gap, which was the click itself.
Screen sharing (#5426)
@RCCore went through WebRTC-internals captures and identified three separate problems. All three were real.
A renegotiation loop. When a stream dropped frames, a watchdog asked the sharer to renegotiate after about six seconds. The renegotiation delivered a new stream, which restarted the watchdog with a fresh counter, so the give-up limit meant to stop this was never reached. On a connection dropping frames because of bandwidth rather than a signalling fault, each renegotiation interrupted the stream and caused the next stall. Requests are now capped at three per sharer every two minutes with a widening gap between them, and the cap resets when a sharer deliberately starts a new share.
Double-clicking the share button started two shares. The join-voice button has had a guard against this for a while; the screen-share button did not. Two negotiations in flight against each other leave the stream stalled and the audio garbled.
Audio starved during the ramp to 1080p. When a share scales up, the video encoder takes the whole uplink for a moment. Audio packets queue behind it, arrive late, and the browser fills the gap with synthesised samples, which is the robotic warble people describe. Audio is a fraction of video's bandwidth, so it is now given priority; the picture barely notices and speech stays intelligible through the spike.
One more, found while in there: screen-share audio that arrived before its video was being filed as voice permanently. The code meant to hold it until the video showed up was never actually reached. It is now held briefly and re-checked, falling back to voice if no video follows, so nobody's speech can go missing.
The desync over a TURN relay reported at the top of that issue was addressed back in 3.26.0 by playing screen audio directly rather than through Haven's own mixer. If you are still seeing drift after several minutes on a relay, that part is worth a fresh report.
Notes
- Restart your server to pick this up.
- Nothing needs configuring. If Auto-Mod is on, the DM check follows the same domain list as everything else.
- No settings changed meaning in this release.