Email is dead.

Apparently.

It has been dead for at least twenty years now, which is quite impressive considering that virtually every company, website, bank, government institution, developer platform and forgotten mailing list from 2003 still insists on sending things through it.

Meanwhile, those of us stubborn enough to run our own mail infrastructure still need something surprisingly mundane:

A good webmail client.

That sounds easy enough. IMAP has been around forever. SMTP is older than some of the people now declaring email obsolete. Surely in 2026 there must be dozens of excellent, lightweight, modern, self-hosted webmail clients to choose from?

Well.

About that.

For quite a while, one of the better answers was SnappyMail. It was lightweight, fast, reasonably modern, worked with standard IMAP and SMTP servers and didn’t require handing your mailbox to a cloud provider just to render some HTML around it.

SnappyMail itself was a fork of RainLoop, another project many self-hosters will recognize. Open source genealogy can sometimes resemble a royal family tree drawn after several centuries of questionable marriages.

Unfortunately, SnappyMail eventually started showing the familiar symptoms of a project losing momentum.

The latest official release, version 2.38.2, dates back to October 9, 2024. There were still occasional commits afterwards, including some maintenance work in 2026, so the repository wasn’t completely frozen in carbonite. But from the perspective of somebody wanting to deploy and rely on the software, releases had effectively stopped while open issues, pull requests and compatibility problems continued accumulating.

That is usually the point where sensible people start looking for alternatives.

I apparently decided to fork it.

“I’ll Just Fork It”

There are several dangerous sentences in software development.

“It should only take an hour.”

“It’s probably just a configuration problem.”

“We can clean that up later.”

And somewhere near the top of the list:

“I’ll just fork it.”

The actual Git operation is, of course, wonderfully trivial.

The consequences are less so.

I started the Tachyon fork from SnappyMail 2.38.2 on June 30, 2026. The original idea was straightforward: preserve what was good about SnappyMail, modernize the parts that were aging, fix some outstanding problems and establish an actively maintained version that could keep moving forward.

Then I started reading the code.

Really reading it.

That is when a fork stops being a GitHub button and starts becoming software archaeology.

SnappyMail already had history behind it because it was itself derived from RainLoop. That means you encounter namespaces named RainLoop, namespaces named SnappyMail, compatibility assumptions accumulated over years, integrations for everything from Nextcloud to cPanel, more than 60 plugins, old build tooling, newer code sitting next to older code, and configuration decisions which must remain compatible because someone, somewhere, absolutely has a production installation depending on them.

This is also where the first rule of Tachyon emerged:

Do not punish existing users for upgrading.

An existing SnappyMail installation should be able to move to Tachyon without somebody spending Sunday afternoon manually reconstructing their mail configuration while searching Stack Overflow for increasingly desperate combinations of PHP error messages.

That requirement has influenced a surprising amount of the project.

The internal namespaces could be cleaned up. The user-facing branding could change. The PHP baseline could move forward. The build system could be modernized.

Persistent configuration and upgrade paths, however, needed considerably more respect.

There are compatibility shims for old RainLoop\ and SnappyMail\ namespaces. Existing SnappyMail data directories can remain in place. The upgrade path deliberately preserves configuration instead of declaring that semantic versioning gives developers diplomatic immunity from angry users.

Forking code is easy.

Forking an ecosystem is where things get interesting.

Why Tachyon?

If you are going to give a fork its own identity, it deserves something better than snappymail-ng-final2-really-final.

I eventually landed on Tachyon.

A tachyon is a hypothetical particle which, according to the fun end of theoretical physics, would travel faster than light.

The name therefore seemed suitably modest for a project whose goals include being a fast webmail client.

It also gave me a clear direction for the project. Tachyon shouldn’t merely be SnappyMail with a different logo. The fork needed a reason to exist.

The focus became three things:

Speed.

Modernization.

And keeping the whole thing firmly within the spirit of self-hosted software.

Tachyon is still fundamentally a webmail client. It talks to your existing IMAP and SMTP servers. It doesn’t invent a proprietary mail backend, require its own database, or demand that your email first make a sightseeing trip through somebody else’s cloud.

The browser talks to Tachyon. Tachyon talks to IMAP and SMTP.

Boring architecture.

I mean that as a compliment.

First, Clean the Basement

Before adding shiny features, there was quite a lot of technical debt to work through.

The original code still supported PHP 7.4.

PHP 7.4 reached end-of-life in 2022.

Software archaeology is fun until the fossils start listening on TCP ports.

Tachyon therefore moved the minimum requirement to PHP 8.2, while the codebase began moving toward modern PHP constructs. Old compatibility code was removed, namespaces were consolidated under Tachyon, and state constants started becoming actual PHP enums.

The JavaScript toolchain received similar attention.

Rollup moved from version 2 to version 4. ESLint moved to version 9 and its newer flat configuration system. Deprecated build dependencies were removed or replaced. CI was added so that PHP syntax checking and JavaScript/CSS linting happen automatically on pushes and pull requests.

None of this produces a particularly exciting screenshot.

That is exactly why it matters.

Projects rarely die because they lack another animated settings dialog. They die because eventually nobody wants to touch the build system, dependencies become impossible to update, releases require occult knowledge possessed by one maintainer, and every innocent-looking change has a 37% chance of summoning a regression from 2017.

A healthy project needs boring machinery.

So I spent quite a bit of time making the boring machinery boring again.

Then Things Got Slightly Out of Hand

Once Tachyon could stand on its own, the project changed character surprisingly quickly.

I originally thought I was creating a maintained successor to SnappyMail.

Then the feature list started growing.

Tachyon now has built-in CalDAV calendar support, including month, week, day and list views, multiple calendars, recurring events, timezone handling and proper treatment of all-day events.

That sounds simple until you implement recurring calendar events.

Anyone who has worked with calendaring standards will understand why the words “recurring event across daylight-saving transitions” can cause an otherwise well-adjusted developer to stare silently into the distance.

Contacts received similar attention.

Tachyon now understands contact groups using the standard vCard CATEGORIES field, which means the group information can survive a CardDAV round trip instead of becoming some application-specific blob. A group can be used directly while composing mail and expanded into its members when the message is sent. Bulk contact operations have also been improved, including safer handling of larger recipient groups.

Mail search has become significantly more useful as well.

Traditional IMAP folder search has an annoying property: it searches the folder you are currently looking at.

This is technically correct.

It is also frequently useless.

Tachyon can search an entire folder subtree. If the IMAP server supports MULTISEARCH, Tachyon can use it. If it doesn’t, the client falls back to searching the relevant folders individually.

That distinction matters to me.

A good network application should take advantage of advanced protocol capabilities when available without turning those capabilities into mandatory deployment requirements.

Protocols have capability negotiation for a reason.

Use the good stuff where you can. Fall back gracefully where you can’t.

The Five-Second Time Machine

One of my favourite additions is Undo Send.

Of course, SMTP does not contain an OH_CRAP command.

Once a message has been handed to the mail server, asking the Internet to kindly forget it is generally somewhere between difficult and comedy.

So Tachyon implements undo-send where it actually makes sense: before SMTP delivery.

When enabled, sending a message places it into a short client-side holding state. You get a configurable window in which you can cancel it before Tachyon performs the actual SMTP transaction.

Simple idea.

Surprisingly useful.

The important part is making the implementation behave like a real feature rather than a JavaScript party trick. Attachments need to survive the delay. HTML and plain-text versions need to be preserved. Pending sends need to survive navigation inside the application.

It is essentially a tiny temporal firewall between your brain and SMTP.

Given the number of emails throughout human history that have been followed immediately by “please ignore my previous email”, I suspect civilization should have implemented this at the protocol layer sometime around RFC 821.

There Is More Web in Webmail Than You Think

A webmail client is an unusually interesting security target.

It takes arbitrary HTML written by people you don’t trust, received from infrastructure you don’t control, and displays it inside the same browser you use for authenticated applications.

What could possibly go wrong?

Quite a lot, obviously.

Tachyon inherited a solid base here from SnappyMail and RainLoop, including message sanitization and OpenPGP support, but the fork has given me an opportunity to tighten the browser-facing side further.

Current versions add stronger Content Security Policy handling, Reporting-Endpoints, a restrictive Permissions-Policy, Subresource Integrity hashes for static JavaScript and CSS, and the usual supporting headers you would expect from a modern web application.

Camera access?

Denied.

Microphone?

Denied.

Geolocation?

No.

Payment APIs?

Nope.

USB?

Also no.

My webmail does not need to know where I am, listen to me, buy anything or communicate with my toaster.

That seems like a reasonable security policy.

OpenPGP remains supported through OpenPGP.js, GnuPG and Mailvelope, and S/MIME support continues to receive fixes as well.

Security work in a mail client will never really be “finished”. Email is a decades-old protocol ecosystem carrying modern HTML through infrastructure designed when finger was considered a perfectly sensible way to tell strangers whether you were logged in.

The best you can do is maintain healthy paranoia.

Fortunately, I have plenty.

A UI Shouldn’t Fight Its Own Theme

Some changes are less protocol-heavy and much more visible.

For example: icons.

A lot of the existing interface relied on emoji for icons.

Emoji are clever, compact and universally supported.

They are also rendered according to whatever artistic interpretation your operating system vendor currently considers appropriate.

Put one into a dark theme and suddenly your carefully designed interface contains a tiny multicoloured object apparently visiting from another application.

Tachyon has moved the interface toward vector icons which inherit the current text colour and therefore behave like actual UI elements.

There is also a proper Dracula theme, including the Alucard light variant, and theme switching can happen without reloading the entire application.

The HTML editor gained table support.

Contacts got better bulk handling.

Account switching now shows unread counts.

Small things accumulate.

That is often what makes software feel maintained.

Keeping It Fast

Adding features creates another classic software-development problem:

Every feature wants to come to the startup party.

The calendar alone produces a minified JavaScript bundle of roughly 129 KB. Loading that for every user would be pointless when plenty of Tachyon installations will never enable the calendar at all.

So it isn’t loaded at startup.

The normal initial JavaScript payload—boot, libraries and the main application—is currently around 337 KB minified and roughly 116 KB over gzip. That is around 70% smaller than the equivalent RainLoop startup payload.

Additional components such as Sieve management and calendar functionality are loaded when needed.

This is one of those places where I think modern web development sometimes loses the plot.

A mail client does not become “modern” because opening your inbox downloads enough JavaScript to emulate an Apollo guidance computer.

Fast software still begins with sending less stuff.

Nextcloud: Because Apparently I Enjoy Compatibility Matrices

One particularly important part of the project has been the Nextcloud integration.

SnappyMail had a substantial Nextcloud user base, which also meant that its stalled release cycle increasingly became a problem as Nextcloud itself kept moving.

Compatibility workarounds and manual patches started becoming part of the conversation around running SnappyMail on newer Nextcloud releases.

That is usually a pretty strong signal that somebody needs to do something.

Tachyon now has its own published application in the Nextcloud App Store, supporting Nextcloud 26 through 35. Existing SnappyMail installations can migrate in place while reusing their existing data.

There are also integrations for ownCloud, Cloudron and Docker, with the wider ecosystem continuing to be cleaned up as the project evolves.

Compatibility work is rarely glamorous.

Nobody posts screenshots proudly announcing that a config directory remained exactly where it was yesterday.

Users notice very quickly when it doesn’t.

And Then People Started Downloading It

One of the stranger moments in any open-source side project is discovering that other people have started using it.

At first, repository traffic is mostly you, a few automated systems and perhaps one search-engine crawler wondering what all the commits are about.

Then numbers begin moving.

Release downloads start appearing.

Issues get opened that you didn’t write yourself.

People install the Nextcloud package.

Someone somewhere apparently decides that deploying software you wrote onto the server containing their email is a perfectly rational thing to do.

That is both gratifying and mildly terrifying.

The early Tachyon releases have already accumulated a healthy number of downloads across the main distribution, ZIP archives, Nextcloud packages, Debian packages and plugins.

GitHub’s asset counters are obviously a crude metric rather than an analytics platform, but the direction is encouraging.

And frankly, crude metrics are fine with me.

A self-hosted webmail project probably should not celebrate adoption by adding enough telemetry to determine what users had for breakfast.

Download counts tell me the useful part:

Someone cared enough to install it.

Tachyon only started on June 30.

At the time I am writing this, less than two months later, the current release is already 4.0.4, published on August 26, 2026.

That version number is perhaps the best summary of how accurately I estimated the scope of this project.

You can follow the releases directly on the Tachyon GitHub repository.

Open Source Is a Relay Race

There is something I particularly like about Tachyon’s history.

RainLoop existed.

SnappyMail took that code and pushed it in a different direction.

Now Tachyon continues from SnappyMail and starts making its own decisions.

That is open source working exactly as intended.

A project does not have to live or die with its original author. Code can outlive maintainers, companies, websites and sometimes entire technology fashions.

The important part is that someone eventually picks up the baton.

That also means respecting the work that came before.

Tachyon contains years of engineering from the RainLoop and SnappyMail developers and their contributors. Starting a fork does not magically make all of that history mine. Quite the opposite: the reason I was able to get Tachyon moving this quickly is that there was already a substantial and capable codebase underneath it.

The interesting question is what happens next.

And this is where Tachyon is becoming its own project.

CalDAV support did not come from changing a logo.

Subtree IMAP search did not come from changing a package name.

Undo Send, contact-group handling, modernized security policies, PHP 8.2, new tooling, compatibility work, UI improvements and the release infrastructure are all part of moving the project forward rather than merely keeping it alive.

There is still plenty to do.

Some old architecture deserves further modernization. There are upstream pull requests worth studying. More parts of the PHP code can benefit from modern typing. The JavaScript side still contains historical choices that warrant long-term reconsideration. Performance can always be examined again. Security certainly can.

And, because this is email, there will undoubtedly be another RFC hiding behind a corner waiting to hit me with an edge case involving a server implementation last updated during the Clinton administration.

Good.

That means there are interesting problems left.

Faster Than Light, Eventually

I don’t know yet exactly where Tachyon will end up.

That is part of the fun.

What began as an attempt to keep a useful piece of self-hosted software alive has already become a much broader project. It has its own identity, its own releases, its own website, its own Nextcloud application and an increasingly distinct set of features.

Most importantly, people other than me are starting to use it.

That changes things.

The moment somebody depends on your software, an amusing weekend fork becomes something you feel responsible for.

So the plan is to keep pushing Tachyon forward: preserve the lightweight nature that made RainLoop and SnappyMail attractive in the first place, modernize the parts that have accumulated rust, improve security and standards support, and add features where they genuinely make webmail better.

Without turning it into a 900 MB Electron application.

I do have standards.

If you run your own mail server, use SnappyMail today, live inside Nextcloud, or simply have an unhealthy interest in IMAP extensions and PHP applications that have survived multiple generations of web development, have a look at Tachyon.

The project lives at tachyonmail.app, with development happening openly on GitHub.

Try it.

Break it.

Open issues.

Send patches.

Tell me which weird IMAP server I accidentally offended.

After all, the nice thing about taking over an abandoned codebase is that you never run out of things to do.

And if Snappy wasn’t quite fast enough…

perhaps it was time for something faster than light.