Hi all 
I run a small ISP, and Nextcloud Talk is how my team actually talks all day — support, on-call, the lot. The official Talk desktop app
works and it’s the reference I learned the protocol from, but a Chromium instance per window is real RAM and latency on the machines my
staff use. I wanted something that opens instantly, idles at near-zero CPU, and survives being left running all week.
So I built TalQ — a native Qt / C++ desktop client for Nextcloud Talk. No web view: the conversation list and messages are drawn
directly with QPainter. It speaks the same Talk HTTP API the official client does; it just renders it the way I wanted to look at it
forty times a day. It’s open source (Apache-2.0).
What works today
- Chat — conversation list (unread / mentions / favorites, sort + filter), bubbles, threads, replies with quoted context, reactions,
read receipts, in-conversation search.
- Files — share from disk or Nextcloud, image previews, a per-conversation “shared files” view; large files now upload in chunks
instead of hitting a size wall.
- Calls — 1:1 and group audio/video over WebRTC, screen sharing with a live thumbnail picker, noise suppression and automatic mic
leveling. Simulcast publishing (180p / 360p / 720p) lets a receiver on a weak link drop down without dragging the whole call with
them.
- Native desktop feel — a tray that behaves, native notifications, four themes, near-zero idle CPU.
- Login Flow v2 — browser login, no password stored.
Where it honestly is
- Windows 10/11 only for now — it uses Windows-specific media/compositor paths; Linux/macOS would need those reworked.
- Beta. Chat is my daily driver and rock-solid. Calls + screen share + simulcast are verified end to end in real 1:1 and conference
use, with a headless self-test suite asserting the publish/subscribe path on every release. The areas that most need outside eyes are
call reliability across the full range of NAT / firewall / device setups and larger (3+) meetings.
Links
What would help most
If you give it a spin, the highest-value feedback is anything about call setup across real networks — if you can reproduce a call
failure with a note on your NAT / firewall / devices, that’s gold. I’m also genuinely curious how much Linux demand there is out
there.
Happy to go into the architecture (native QPainter rendering, GStreamer WebRTC pipelines) if anyone’s interested.
— Kalin
TalQ is an independent, unofficial client. “Nextcloud” is a registered trademark of Nextcloud GmbH; TalQ is not affiliated with or
endorsed by Nextcloud GmbH.
Small update, about a week on — thanks for all the early interest.
I’ve been heads-down on call quality since posting. Video and screen-share now publish in simulcast (several quality layers at once) and adapt the bitrate to your connection live, so everyone on a call gets the best their own link can carry instead of dropping to the weakest one. Screen-share scales up to 4K. And the encoder overload that could freeze video on older or weaker machines is fixed — it now eases quality down under CPU load instead of stalling.
Threads/Topics got proper UI support too: thread-aware message routing and a reply-preview, so a side conversation doesn’t bury the main one.
Also since the post — a few stable releases (latest is 0.50 “Slartibartfast”), a fix so a call survives a peer’s brief Wi-Fi drop, and echo cancellation. Still beta, still Windows-only for now, but it’s getting solid. More soon.
I have a lot of interest in a Linux Qt app for Talk. Like, maybe just me alone, but I’m very interested 
Especially since on some of my Linux machines the Electron app quite simply isn’t available and I have not been able to compile it (it’s amazing that somehow JavaScript-based applications are the least portable applications around, and yet!).
Previously my hopes were on resurrecting GitHub - CarlSchwan/talk-desktop: Nextcloud talk unofficial desktop client · GitHub which is built using Kirigami, a KDE app framework atop Qt, and forked from the still-somewhat-active SailfishOS Talk client. That Kirigami app should also compile for Windows (and MacOS even) too, though I haven’t tried that; currently I’m stalled out on getting it to compile with Qt6 rather than just Qt5, and the original creator has been stalled out for years now on the basis of not actually using Nextcloud Talk anymore.
Unfortunately, as that implies my CMake-fu for Qt apps is rusty at best, but I’m hungry enough for a non-Electron (and especially actually-works-on-ARM) native client that you’d better believe I’m gonna try and get your app building on Linux too!
Ha — honestly this made my day. A native client that actually works on ARM is half the reason I didn’t just bundle a web view and call it done, so no, you’re definitely not alone in wanting this. And yeah, the “JavaScript is somehow the least portable thing on earth” paradox is exactly the itch I was scratching.
So here’s the honest state of things. It’s Windows-only right now, but not because it’s deeply tangled into Windows — it’s more shallow than that. All the actual app — the chat, the sync, login, the whole UI — is just plain Qt6 (Network, WebSockets, SQL, and the UI is hand-painted with QPainter). That stuff should come up on Linux with barely a fight. The calls run on GStreamer, which is already cross-platform; the only Windows-specific bits are the element names at the very edges of the pipelines — the camera grabber, the audio in/out, the screen capture. Swap mfvideosrc for v4l2src, the WASAPI bits for PipeWire/Pulse, and the whole Direct3D/Windows-Graphics-Capture screen-share path collapses into a single PipeWire portal source on Linux (you actually get to delete a chunk of native code rather than port it). The GPU/encoder picking is DXGI-based today, but on Linux that’s VA-API or v4l2 — and v4l2 stateful encoders are precisely the ARM story.
The catch is honest too: those element names are currently hardcoded inline in a few of the pipeline files, so the real first job is carving out a little “pick the right element for this OS” seam, plus teaching CMake to stop assuming an MSYS2 layout. Don’t sweat the rusty CMake — that part I’ll just do with you.
If you’re game, the sweetest starting point isn’t audio or video at all — it’s getting a chat-only build to compile and run on Linux with calls stubbed out. That proves the Qt core is clean and gives us solid ground to bolt the media backends on one at a time, instead of fighting everything at once.
I went ahead and opened a tracking issue so there’s somewhere real to push against — staged build → chat → audio → video → screen share, with the full element map already written up: Linux port (incl. ARM) · Issue #2 · kalinbogatzevski/talq-desktop · GitHub. Jump in there whenever. Genuinely excited someone wants to take this where I can’t easily test.