ihasmail Was Written for One User

There is some confusion about what ihasmail is, and lately a bit of effort spent framing it as a contest it never entered. Both are easy to fix, so here is the whole thing, plainly.

It was written for one mailbox: mine

The first commit is dated 18 October 2025. I had been self-hosting my own mail for longer than I care to admit and had landed on Stalwart, which gives you mail, calendars, contacts, filters and file storage out of a single binary with a config you can actually read. What I did not have was a browser client that treated it as any of that. I was on Roundcube.

Roundcube is good software, and I want to be unambiguous about that, because "I replaced Roundcube" reads as an insult and is not meant as one. It has quietly run a large share of the world's self-hosted webmail for two decades. But it comes from the IMAP era and it has never pretended otherwise: IMAP for mail, SMTP for sending, CalDAV for calendars, CardDAV for contacts, and a database of its own for everything those protocols cannot express. Point it at Stalwart and you have an IMAP-era client bolted to a JMAP-era server, using none of what makes the server interesting. It felt dated because it is dated, in the specific and forgivable sense that the world it was designed for is not the one my server lives in.

So I did what nerds do. I wrote my own. For me, on one server, with no plan for anybody else to ever run it.

That is not modesty or a founding myth. It is the reason the software is shaped the way it is, and it explains most of the decisions people ask me about.

Then I pushed it, and people showed up

On 23 August 2026 I pushed the v2 code — a rebuild as a Stalwart-first JMAP client — and announced it. That was just over two weeks ago.

It went better than I expected. People turned up and filed bug reports, several of them very good, and asked for things I had not thought of. Since that day, 32 issues have come in from people outside the project, and every one of them is closed. Most were adopted: the bug got fixed or the enhancement went in, usually within days. Nobody was owed that response and nobody paid for it — I did it because a stranger taking the time to write a careful bug report against your weekend project is a gift, and the correct response to a gift is to use it.

That is the part I did not plan for and now think is the best thing about the project.

What it is

Five rules, unchanged since the first commit:

Lean. No database. No IMAP. No SMTP. No CalDAV or CardDAV. One protocol — JMAP — plus Stalwart's blob, upload and EventSource endpoints. Everything durable belongs to the mail server, because the mail server is already the thing you back up.

Fast. JMAP batches. "Archive these forty messages and update the counts" is one round trip, not forty. Change tracking and server push mean a message read in Thunderbird disappears from the browser without a refresh.

As few moving parts as possible. It is one container in front of your existing server. With IMMUTABLE=1 it runs read-only with no volume at all. There is no admin panel, no plugin system, no second service to stand up, and nothing to keep in sync.

Disposable, and that one is a goal rather than a consequence. What I actually wanted was a webmail container I can destroy and recreate in seconds, anywhere, without burning a single synapse on reconfiguring it or syncing it back up afterwards. Deploy is the only step. There is no step two — no migration to run, no cache to warm, no state to carry across, nothing to restore, and nothing left behind when the old container goes. Move it to a different host and the only thing that changes is where it runs. Everything that matters was always on the mail server, which is the one machine you were backing up anyway.

Feature rich. Lean is not the same as thin. Mail, threads, calendars, contacts, file storage, a visual Sieve filter builder, nine interface languages, PWA push that arrives with the app closed. FEATURES.md is fourteen thousand words and lists the Stalwart capability each feature needs, so you can tell in advance what your server will and will not give you.

Those pull against each other constantly, and every interesting decision in the project has been about where exactly to give.

What it is not

It is not a Roundcube replacement project. It replaced Roundcube for me. If Roundcube fits your setup, it is mature, well understood, and supported by people who have been doing this longer than I have. Nothing about my project is an argument that you should stop using theirs.

It is not competing with Bulwark, and it is not a response to it. I want to put a date on this because dates settle it: ihasmail's first commit is 18 October 2025. The bulwarkmail organisation on GitHub was created on 10 March 2026, and its webmail repository three days after that. When ihasmail started, Bulwark did not exist. It could not have been built in reaction to something that was not there, and it was not. That is chronology, not a claim about merit — theirs is a serious project doing serious work, and the five-month gap says nothing at all about which is better for you.

Parity is not a design goal. Not with Bulwark, not with Roundcube, not with Gmail. A feature goes in when it earns its place against those rules, and "the other one has it" is not an argument that it does. Chasing someone else's feature list is how you end up with their architecture, and their architecture is not the one I want. Both instincts here are defensible — how much a webmail should keep is a real design question with more than one right answer — but they are genuinely different instincts, and the useful thing for you is knowing which one you want, not knowing which project won an argument.

Why there is a comparison page anyway

Because I was asked, repeatedly, and a straight answer is more useful than a diplomatic one. So ihasmail.org/compare-bulwark.php exists.

It is written under rules I would want applied to me. Their side comes from their own published material — their README and FEATURES.md — and not from my impression of it or from reading their source. Where their docs are silent, the page says so rather than treating silence as absence. Both columns carry their own date, because a comparison stamped with today's date after re-reading only one project is worse than no date at all. The 7 September pass read their FEATURES.md as well as their README, and most of what it changed was in their column and in their favour: the first draft had credited them with less than they document.

And it shows plenty of places where we are behind. It is supposed to. A comparison page that finds its author winning every row is a sales sheet, and everyone can tell.

If you read it and Bulwark is the better fit for you, run Bulwark. I mean that without any hedging. There are two AGPL webmail clients being actively built for Stalwart right now, by people who care about the details, and that is a better position than this ecosystem was in a year ago.

Saying no is a feature

ROADMAP.md is eight entries long and it is not a plan. It is the list of things ihasmail does not do, each with the reason it does not. Mail folder sharing, because Stalwart stores the share and never delivers it. Snooze, because nothing could act on your mailbox while the app is closed and ihasmail never stores a password. Encryption at rest, because turning it off does not decrypt what is already there, and a switch that reads as "make my mail safer" while quietly being irreversible is the wrong thing to hand an ordinary person.

A "not yet" that is really a "no" should say so, and it should say why. Every request I have declined is on that page with its reasoning, which is the least I owe someone who took the trouble to ask.

The whole ambition

It is still software written for one user, that other people now happen to run. Weekly images, an issue tracker I answer, an honest comparison page, and no intention of turning it into anything else.

If it suits your server, it is AGPL-3.0 and right here. If it does not, one of the others will, and that is a fine outcome too.