Client Interfaces: One Contract, Several Clients

Nuncio's architecture is one daemon publishing a single versioned gRPC contract, consumed by separate, thin client projects. Today that contract has exactly one working client. The rest below is the intended design, not a working feature.

Reference CLI (`nuncio-cli`)Available now

A scriptable, noun-verb command-line client and the project's own end-to-end test driver. Build and run it today with cargo run -p nuncio-cli.

Desktop GUIPlanned

A native desktop app consuming the frozen gRPC API, planned as a separate client repository. Not built yet.

Terminal TUIPlanned

A keyboard-driven terminal client over the same API. The keybinding table below is the intended design for this client, not something you can run today.

MCP AI ClientPlanned

A governed bridge letting AI agents work with your mail through capability policies. See the MCP page for the full design.

Intended Terminal TUI Keybindings

Design draft

j / kMove message focus cursor down / up

h / lSwitch pane focus between folder tree and message preview

eArchive focused email

sToggle star / flag status

dMove email to trash

fOpen NSQL filter rules view

aOpen account switcher

/Focus full-text search bar

qQuit the TUI (daemon keeps running)

What "Feature Parity" Means Here

Because every client is a thin layer over the same gRPC contract, feature parity across clients is a property of the contract, not of separate implementations staying in sync by discipline. That is the design goal for GUI, TUI, and MCP once they're built — it is not a claim that they exist today.

Previous GuideAccount Setup (Planned)

Next GuideNSQL Language Specification