Every repository that matters
The honest map of the Pimalaya organisation: what you can install today, what is brewing, and what has been retired. Statuses are curated by hand; when in doubt, the repository's README is the truth.
Roadmap
Mail is now the most complete domain of the ecosystem, especially with Himalaya v2. The focus therefore moves to what surrounds it: sync, watch, then contacts, then calendar.
Sync comes first, as a consolidation: everything sync-related converges into one stack, the Neverest CLI on top of the io-replica engine and the pimdir store. Watch joins the same movement, with mirador rebranded to Carillon.
Once sync and watch settle, the contacts domain gets the same treatment around Cardamum, then the calendar domain follows around Calendula.
Libraries
The foundation: every app is a thin frontend over these Rust crates. A curated selection, as the organisation holds more (per-store coroutines, toolkit crates, experiments). The io- prefix marks I/O-free, sans-I/O coroutine libraries: you bring the sockets, they bring the protocol.
| Name | Domain | Kind | Status | What it does |
|---|---|---|---|---|
| mml | Library + CLI | stable | Compose MIME messages as human-editable markup (MML), Emacs-style. | |
| io-imap | Library | stable | I/O-free IMAP client. | |
| io-smtp | Library | stable | I/O-free SMTP client. | |
| io-oauth | Auth | Library | stable | I/O-free OAuth 2.0 flows: authorization code, device, dynamic registration. |
| io-http | Transport | Library | stable | I/O-free HTTP client core the other crates build on. |
| stream | Transport | Library | stable | Standard I/O connectors that drive the I/O-free crates. |
| io-webdav | Contacts + Calendar | Library | early | I/O-free CardDAV and CalDAV clients over WebDAV. |
| io-jmap | Library | early | I/O-free JMAP client. | |
| io-maildir | Library | early | I/O-free Maildir store. | |
| vcard | Contacts | Library | early | vCard parser with a byte-faithful round-trip. |
| io-pim-discovery | Plumbing | Library + CLI | early | Discover a provider’s IMAP, SMTP, CardDAV and CalDAV services from an email address. The CLI ships as an off-by-default cargo feature. |
| io-gmail | Library | early | I/O-free Gmail REST API client. | |
| io-msgraph | Email + Contacts | Library | early | I/O-free Microsoft Graph client (mail and contacts). |
| io-m2dir | Library | early | I/O-free m2dir store. | |
| io-people | Contacts | Library | early | I/O-free Google People API client. |
Apps
End-user tools. Anything marked in development has no release yet and is not advertised on the home page.
| Name | Domain | Kind | Status | What it does |
|---|---|---|---|---|
| comodoro | Time | CLI | stable | Manage Pomodoro-style timers from the command line. |
| himalaya-vim | Vim plugin | stable | Manage emails from Vim, on top of the Himalaya CLI. | |
| ortie | Plumbing | CLI | stable | Manage OAuth 2.0 tokens for your accounts, with a provider wizard. |
| neverest | CLI | beta | Synchronize and back up emails between two backends. | |
| cardamum | Contacts | CLI | early | Manage contacts over CardDAV, Google, Microsoft and JMAP address books. |
| sirup | Plumbing | CLI | early | Spawn pre-authenticated IMAP and SMTP sessions, exposed over Unix sockets. |
| himalaya-tui | TUI | in development | A full-screen terminal UI for reading and writing emails. | |
| pimalaya-android | Email + Contacts + Calendar | Android app | in development | Mail, contacts and calendars in one Android app, over one local store and one account list. Contacts are the mature domain; mail and calendar are read-only for now. |
| tcard | Contacts | CLI | in development | Edit vCards as friendly TOML. |
| calendula | Calendar | CLI | in development | Manage calendars over CalDAV. |
| m2m | CLI | in development | Convert mail stores between Maildir, Maildir++ and m2dir. | |
| tcal | Calendar | CLI | in development | Edit iCalendar events as friendly TOML. |
| pimalaya-linux | Email + Contacts | Desktop app | in development | A native GTK4 and libAdwaita desktop app for mail and contacts, sharing its configuration file with the command-line tools. |
| mirador | CLI | retiring | Watch mailboxes for changes; its watch features fold into the next generation of tools. |
From the community
Front-ends and integrations built by other people on top of the tools and the crates, none of them maintained by the organisation. The list is curated by hand and certainly incomplete: if you built something, open a pull request on the websites repository and it lands here.
| Name | Author | Kind | What it does |
|---|---|---|---|
| himalaya-emacs | dantecatalfamo | Emacs plugin | Browse, read, write and organize emails from Emacs, on top of the Himalaya CLI. Published on MELPA. |
| mailbrus | antono | Desktop and web app | A keyboard-driven, plain-text-first email client built on the io-email and io-maildir crates, shipped as a Tauri app and a progressive web app. |
| himalaya.nvim | knownasnaffy | Neovim plugin | A native Neovim interface to the Himalaya CLI, written in Lua on top of nui.nvim. |
| himalaya.nvim | JostBrand | Neovim plugin | A Neovim port of himalaya-vim, with folder pickers backed by fzf or Telescope. |
| himalaya-nvim | xav-ie | Neovim plugin | A heavily modified Lua fork of himalaya-vim, with threaded views, structured search, HTML rendering and flag management. |
| himalaya-wrap | robertmeta | Emacs plugin | An Emacs front-end to the Himalaya CLI designed for Emacspeak users, working straight against the remote server with no local maildir. |
| himalaya | jns | Raycast extension | Read and manage the emails of your default account from the Raycast launcher on macOS. |
| dfzf | parisni | Sway and i3 toolkit | A fuzzy-finder desktop toolkit whose dfzf-mail viewer runs on the Himalaya CLI and mml. |
| himalaya SKILL | openclaw | Agent skill | Teaches the OpenClaw coding agent to manage emails through the Himalaya CLI. |
Frozen and retired
Kept public for history and existing users, but receiving no new features. Frozen aggregators are superseded by protocol-direct clients; deprecated crates should not be depended on.
| Name | Domain | Kind | Status | What it does |
|---|---|---|---|---|
| io-email | Library | frozen | Multi-backend email aggregator; superseded by protocol-direct clients. | |
| io-addressbook | Contacts | Library | frozen | Multi-backend contacts aggregator; superseded by protocol-direct clients. |
| io-calendar | Calendar | Library | frozen | Multi-backend calendar aggregator; superseded by protocol-direct clients. |
| io-process | System | Library | deprecated | Process-spawning coroutines. |
| io-keyring | System | Library | deprecated | Keyring coroutines; tools now document third-party keyring CLIs instead. |
| io-fs | Storage | Library | deprecated | Shared filesystem coroutines; each store now defines its own. |
| mimosa | System | CLI | deprecated | Secret-management CLI, retired with io-keyring. |
Experiments
Running on the side, each experiment validates one idea before it is allowed to shape the roadmap.
Carillon explores watching as a service: a server holds the IMAP connections, waits for changes, and turns them into notifications, so no client has to keep a connection (and a battery) alive. It validated the watch flow end to end against real providers; that flow is what the roadmap folds into the watch tooling. Its paid, hosted side is paused for now.
pimalaya-android validates that the I/O-free Rust libraries can power a real mobile app: the protocol logic runs in Rust, compiled for Android, while the platform side (TLS, storage, the system contacts) stays native. It started as a contacts app and became the whole thing, mail, contacts and calendars behind one store and one account list, which is the second point it validates: the three domains belong in one app, not three. Contacts is where it is mature; mail and calendar read today and will write later. A blog post about the approach is coming soon.
pimalaya-linux carries the same idea to a third ecosystem: a native GTK4 and libAdwaita desktop app for mail and contacts, built on the very same Rust cores, to prove the libraries fit any UI (terminal, mobile or desktop) without rewriting the protocols. It reads the same configuration file as the command-line tools, so one account definition serves all of them. Only the application shell exists so far.