This is not the first time. Pimalaya has been sustained by NGI programs for years, and every one of those years turned into libraries, CLIs and apps that anyone can read, fork and reuse under a free licence. This one comes with a theme: a filesystem standard for PIM resources, and the work around the rest of the stack that makes such a standard worth having.

What follows is a direction, not a roadmap. The detailed plan is yet to be written.

Consolidating what already exists

The least glamorous part of the year, and probably the most valuable.

Pimalaya is by now a fairly wide set of low-level Rust libraries: protocol clients (io-imap, io-smtp, io-jmap, io-webdav), local formats (io-maildir, io-m2dir, io-vdir), provider APIs (io-gmail, io-msgraph, io-gcal, io-people), the plumbing they all sit on (io-http, io-oauth, io-proxy, io-pim-discovery), and the content models (vcard-rs, ical-rs).

They share one architecture: I/O-free coroutines, state machines that hold the whole protocol logic and perform no I/O themselves, plus a thin reference client that services their requests. It is what lets the same IMAP code run in a blocking CLI, in an async daemon, and behind a JNI transport on Android without a rewrite per runtime.

That set is already solid. What it needs now is not more surface but more depth: stable published APIs, real documentation on docs.rs, test coverage that means something, fewer half-migrated dependents, and releases that consumers can actually pin. Consolidation is what turns a pile of promising crates into a stack somebody else can build on, and that is the point of building it in the open in the first place.

pimdir, a standard for PIM on disk

The named deliverable. pimdir is a specification for how personal information lives on a local disk: mail, contacts, events, notes, tasks, one store, one format.

The existing conventions each solve one domain: Maildir for mail, vdir for contacts and calendars. They are file-per-item layouts, and that shape has known limits. Listing a mailbox means opening thousands of files. Filenames carry state, so a flag change is a rename. Case sensitivity, forbidden characters and path length limits differ per filesystem, so a store that works on Linux is not automatically a store that works on Windows or on Android. And a multi-item move is a sequence of independent renames that a concurrent reader can catch halfway through.

Pimdir keeps the part those layouts got right, the large immutable content beside the index, and takes the part every serious PIM application already reaches for, an indexed binary store. A store is a directory with two things:

• pimdir.db, a SQLite database holding collections, items, per-source bindings and sync checkpoints,
• objects/, a content-addressed blob directory holding the item bodies, one immutable file per content hash, sharded two levels deep.

SQLite is a deliberate choice: its file format is byte-identical across every OS and architecture, with a stability commitment through 2050. You copy a store, you do not run a server.

A few ideas do most of the work. A collection declares a media type and the store never parses the bodies, so mail, contacts and calendars are the same tables. Bodies are content-addressed, so an item filed in two collections is stored once and a copy or a move is a pointer edit rather than a byte copy. Identity is split into four distinct things (the backend handle, the cross-collection link id, the content hash, and a short public id that clients display) instead of one identifier asked to be all of them. The database is a derived cache, rebuildable from the blobs and a fresh sync. One process owns it, readers open it read-only, and anything else appends to an action queue the owner applies in order. And a removal is retention, not deletion: when the last source drops an item the row is kept until an explicit purge, so a remote expunge never destroys the local copy.

The specification is still a draft, it lives in the repository next to its canonical SQL schema and queries, and io-pimdir is the reference Rust implementation. Draft means it can still move, and this is the year it should stop moving.

Sync, built on pimdir

A store format is only half the story. The other half is keeping it in agreement with a remote.

That layer is io-replica, an offline-first replica engine written in the same I/O-free style. It reconciles local and remote changes with a three-way merge against a stored base, so an edit made offline survives the next sync instead of being silently overwritten. It deduplicates, so an item in several collections is fetched once. It caches partially, so a collection can be known by identifiers, by summaries or in full, and still tell "deleted" apart from "not fetched yet". Flags merge without ever conflicting; diverging bodies are kept on both sides for a human to resolve.

The interesting consequence of putting this above a generic store is that it stops being a mail feature. The engine reconciles collections of items; what an item is, it does not care. Sync, backup, mirroring and one-off migration between two backends become the same machinery under different policies, and Neverest is the CLI that exposes them.

More domains

The stack was built for mail first, and mail is in good shape: IMAP, SMTP, JMAP, Maildir and the provider APIs, driven by Himalaya and its TUI.

Contacts followed and are close behind: Cardamum speaks CardDAV, vdir, Google and Microsoft, on top of vcard-rs, which carries a version-agnostic vCard model, a byte-faithful syntax tree, and the jCard and JSContact conversions.

Calendars are the current front. Calendula is taking shape over CalDAV and local vdir, on top of ical-rs, the iCalendar twin of the vCard library, JSCalendar and three-way merge included.

Tasks are the plausible next one, and cheaply so: a to-do is a VTODO, which the iCalendar model already parses, and a task list is a collection of a media type the store already accepts. That is the whole argument for doing the generic work first: adding a domain should be a connector and a media type, not another silo.

Higher interfaces

None of the above is something a user sees. Interfaces are, and they are where the layering finally pays off.

The terminal is well covered: a CLI, a TUI, editor plugins. What is missing is everything else. There is a native GTK4 and libAdwaita desktop application for Linux, and Android apps for mail, contacts and calendars converging into one client. Both are being replanned onto io-replica and io-pimdir, which is exactly the intended shape: an interface should be a view over the local store, fast and useful with no network at all, with sync happening behind it rather than in front of it.

An offline-first store is the feature that makes a mobile client tolerable and a desktop client pleasant. That is why the plumbing year comes first.

In short

One store format, one sync engine, more domains behind them, and interfaces that are finally just views. That is where the coming year points.

It is a direction and not a plan: the specification is a draft, the priorities will move as the work meets reality, and the detailed roadmap is still to be defined. What is certain is that all of it lands in the open, under free licences, as it always has.

Thanks to NLnet and to the NGI programs for making the slow, unglamorous, load-bearing part of this possible. Follow along here, or on Matrix and Mastodon.

Mails inside Vim

Years ago I discovered Vim, and like many people who fall into it, I fell hard. Once your editor becomes the place where you think, you want everything in it: notes, tasks, code, and, in my case, mails.

So I wrote iris.vim, a plugin to manage mails inside Vim. Reading, replying, archiving, without leaving the editor.

The reception was… polarized. Some people hated me for torturing Vim: it is a text editor, not a mail client, and the plugin ecosystem was never meant to carry a mail workflow. Others loved the concept: their editor was already their home, and mail was the one thing still dragging them elsewhere.

Both sides were right, and that tension turned out to be the founding insight of everything that came after.

Splitting the UI from the logic

The critics had a point: Vim is a terrible place to implement a mail client. Fetching, parsing, encoding, talking to servers: none of that belongs in a plugin. But the lovers had a point too: Vim is a wonderful place to display one.

This is where I started to split the UI from the logic. The domain (everything mail knows how to do) should live outside the editor, in a proper program. The editor should only be a frontend: buffers in, keystrokes out.

Once the logic is its own program, the frontend becomes swappable. Vim today, something else tomorrow.

A CLI, in Rust

The shape of that program came naturally: a command-line interface. I had wanted to learn Rust for a while, and a mail CLI fit perfectly: innovative (the terminal mail world was full of TUIs like mutt, but a plain, scriptable CLI was rare), the right size for learning a new language, and exactly the backend a Vim frontend needed. The plugin would just shell out and render the output.

That CLI became Himalaya.

Then it grew

The CLI was supposed to be the end of the story. It was actually the beginning, and the same splitting instinct kept applying itself one level down:

• The email logic was extracted from the CLI into a dedicated library, so other tools could reuse it.
• The protocol logic was extracted from the email library into low-level libraries (IMAP, SMTP, and friends), so the email layer itself became swappable.
• A TUI joined the CLI, proving the point of the whole architecture: same logic, another frontend.
• Then other PIM domains knocked on the door: if it works for mails, why not contacts? Why not calendars?

At some point this stopped being "the Himalaya ecosystem" and became its own project: Pimalaya.

Here we are

Today Pimalaya is full of low-level libraries, and fully mail-capable: Himalaya CLI, a TUI, mobile apps on the way. Contacts are coming next, then calendars.

The plugin that tortured Vim is long gone, but its lesson is load-bearing in everything we build: the domain logic lives in reusable layers, and the UI (editor, terminal, phone) is just a view on it.

Not bad for a plugin some people hated.

Pimalaya is an ambitious project that aims to improve the open-source tooling around personal information management (also known as PIM): emails, contacts, calendars (events, tasks, journals, alarms), timers, files, and whatever else turns out to belong there.

It comes in two halves. The libraries are low-level Rust crates for protocols and storage, reusable by anyone. The applications are what we build on top of them: CLIs, TUIs, editor plugins, mobile apps and native desktop GUIs.

One rule binds them together: the libraries are I/O-free. They carry the whole protocol logic as state machines and perform no read, no write and no network call of their own, so the application stays in charge of blocking or async, of which runtime and of which TLS. That single constraint is why the same IMAP code can run in a terminal, in a daemon, and inside an Android app over a Kotlin-owned socket.

Today mail is the mature domain (a CLI, a TUI, Vim and Emacs plugins), contacts and calendars are catching up, mobile and Linux desktop applications are underway, and the offline-first sync stack is the current frontier.

Why a blog

What Pimalaya has used for a while:

• Website: the front door. What Pimalaya is, and where everything else lives.
• GitHub: the code, the bug reports, and the design discussions that lead to decisions.
• Matrix: real-time chat and support. Nothing said there is meant to last.
• Mastodon: the megaphone. Short announcements pointing at something durable.

What it never had is a durable place, where the project's direction gets written down in full sentences: why a release took the shape it did, what is coming next, and what got retired along the way. This blog is that place. The RSS feed and the newsletter are just two read-only views on it: subscribe to whichever fits your reading habits.

What to expect

Three kinds of posts, all in the same half-technical register.

• Journal and news: the running account of the project, on both the PIM domain side and the technical side (what is being built, reworked, or retired, and why). This is the logbook behind the short Mastodon announcements.
• Architecture and design: the reasoning behind how Pimalaya is built. These posts lean more technical than domain: the choices, the trade-offs, the alternatives that were rejected, and the patterns shared across the libraries and the applications.
• Releases, in depth: when something ships, the release post goes further than a changelog. What changed for users, what changed under the hood, and the decisions behind both.

Expect the occasional detour into a dead end we walked into and walked back out of. Those are usually the most instructive ones, and they never fit in a changelog.

See you in the feed.