Corvus

2024 · Concept

A native Linux email client in Rust and GTK4

RustGTK4libadwaitaJMAPFlatpakSQLite

The problem

Every mail client on Linux asks you to give something up. Electron-based clients cost hundreds of megabytes of RAM to render a list of text. The established native clients work, but their interaction model predates the smartphone. And the clients that added AI features did so by shipping the contents of your inbox to someone else's inference server — which, for a mailbox that contains anything sensitive, is not a trade worth making.

Architecture

JMAP as the primary protocol

IMAP was designed for a world of persistent connections and small mailboxes, and its statefulness makes efficient synchronisation genuinely difficult. JMAP is a JSON-over-HTTP protocol with a proper change-tracking model: the client asks what changed since a given state string and receives exactly that. It maps cleanly onto an async Rust client, batches well, and degrades sanely on a mobile connection. IMAP support remains a compatibility layer rather than the foundation.

GTK4 and libadwaita for the interface

libadwaita provides adaptive layouts, so the same widget tree serves a maximised window on a desktop and a narrow window on a laptop without a second codebase. It also means Corvus inherits the platform's accessibility stack, dark mode and keyboard conventions instead of reimplementing them badly. The Rust bindings (gtk4-rs) are mature enough that the interface layer is ordinary Rust rather than an FFI exercise.

Local inference only

Categorisation, summarising a long thread and drafting a reply all run against a model on the user's own machine. This constrains model size, which in turn constrains what the feature set can promise — a deliberate trade. The alternative, sending mail bodies to a hosted API, would make the client unusable for exactly the people who care most about their mail.

Local store and offline behaviour

Messages and metadata live in a local SQLite database, so search and reading work with no network at all. Synchronisation is a background task reconciling the local state string against the server's, which keeps the interface responsive while a large mailbox catches up.

Decisions

Rust over C or ValaRust with gtk4-rs: A mail client parses untrusted input from the network all day: MIME structures, HTML bodies, malformed headers from two decades of broken senders. Memory safety at that boundary is worth more than the convenience of Vala's tighter GObject integration.
JMAP first, IMAP as fallbackJMAP as the native path: Building IMAP first and bolting JMAP on later would have shaped the entire synchronisation model around IMAP's assumptions. Doing it the other way round means the fallback is the compromise, not the core.
Flatpak as the distribution formatFlatpak, single manifest: Packaging separately for every distribution is a job in itself. Flatpak also gives a sandbox by default, which matters for an application that renders remote HTML.
No hosted AI backendLocal models only: It caps the feature ceiling and it means slower inference on older hardware. It also means the client can be recommended without an asterisk.

Installation

Once the first Flathub release is out, installation will be:

flatpak install flathub de.nkoeberlein.Corvus

Corvus is at concept and early implementation stage — there is no release to install yet. The repository is the honest picture of where it stands.

What it is not

Corvus is not a webmail frontend in a window, and it is not trying to be a groupware suite. No calendar, no contacts manager, no chat. Every one of those is a project in its own right, and bolting them on is how mail clients become slow. If it ever ships a calendar, that will be a separate application that happens to share a design language.

All projects