Case study · Rust / Android
rust-connect
The problem
KDE Connect makes an Android phone feel native on a Linux desktop: notifications, clipboard, files, media controls, SMS, and remote input travel between the two. Its Linux application is built on Qt and KDE libraries. GSConnect integrates with GNOME Shell. rust-connect takes a third route for users who want neither desktop stack.
rust-connect provides a compatible protocol surface as a desktop-environment-independent user service. The stock KDE Connect Android app stays on the phone; the Linux side is Rust, a local REST API, and no desktop-environment dependency.
The framing
Completeness is measured against KDE Connect and GSConnect, not against the features one user happens to need. A plugin cannot advertise a capability it does not honor. Unfinished features get finished or stop advertising temporarily; they do not disappear to make the roster look tidy.
The control surface follows the opposite rule. One authenticated REST API on localhost serves the CLI, troubleshooting UI, Swagger documentation, and event stream. An MCP layer is deferred; the REST API is the current control surface.
The build
Rust, Tokio, Axum, rustls, and zbus. Discovery uses complementary mDNS and UDP broadcast paths. Pairing uses mutual TLS 1.2, trust-on-first-use certificate pinning, and the same timestamped Short Authentication String Android displays. Payload transfers open a second bounded TLS connection, matching the reference protocol.
The registry contains 24 protocol plugins, including file sharing, notifications and replies, SMS, contacts, battery, connectivity, clipboard, MPRIS media control, mouse and presenter input, remote commands, and SFTP. Some require desktop facilities or manual setup and degrade when those facilities are absent. Clipboard integration drives the real Wayland session. MPRIS talks to actual media players over D-Bus. The daemon ships as a systemd user service because identity, downloads, notifications, clipboard, and media control all belong to the logged-in session.
The proof
More than 900 automated tests cover the protocol, API, CLI, hostile peers, transcript replay, property cases, and fuzz targets. Those tests are one evidence layer. The wire contract comes from the Android and KDE sources, and the final interoperability check is a stock Android phone.
The public live-device matrix records discovery and reconnect behavior, daemon-initiated
fresh pairing with matching SAS values, upgrade continuity, file transfer in both directions,
notification mirroring, clipboard in both directions, battery, and connectivity. The v0.1.0
release does not display the desktop SAS during phone-initiated pairing; that path was fixed
on main in
PR #9.
The outcome
v0.1.0 is public under GPL-2.0-or-later. The release ships a Debian package and a standalone Linux binary, with CI, dependency auditing, fuzzing, a threat model, troubleshooting guide, protocol references, and a live-device validation matrix in the repository.
The build also produced a more useful engineering result than a feature count: a clear boundary between tests that confirm an implementation and evidence that confirms the implementation understood the protocol.