New Project: D2D Mail+Cal Client — An Open-Source, Cross-Platform, Privacy-Respecting Email, Calendar, and Contacts Application

The Last Straw

For the past several weeks, the staff at Practicing Musician SPC have been migrating away from commercial cloud (Azure, AWS, GCP, etc.) to our fully open-source, privacy-and-intellectual-property-considerate infrastructure. We're building the ClimbHigh.AI platform to help IP owners get full transparency, privacy, respect, and attribution — rather than having their work stolen by large aggregate AI harvesters like Google, Microsoft, GitHub, and others. As part of that migration, we moved to self-hosted email, calendaring, and contacts running on our Harvester cluster. The migration is going reasonably well and should be complete by the end of this month.

What has been more of a thorn in the side is the client-side email and calendaring. While most of the other platform tools work reasonably well (chat, LMS, VMS, video conferencing, etc.), the email and calendaring have been problematic.

Every team member has a different combination of devices — Android phones, iPhones, Linux desktops, Windows laptops, a couple of Macs — and getting email, calendars, and contacts working reliably across all of them has been an ongoing struggle. Different apps on different devices, different sync behaviors, different things breaking in different ways.

Then today, my wife — who was using Thunderbird on Android for her calendar — asked me if there was a solution she could trust, because she was worried she was missing important appointments across several of her calendars. She wanted one app that handled her email and calendars together, on her phone, without routing her data through Google or Apple.

I couldn't give her a good answer. Not a secure one, anyway. Not one that worked across all her devices.

That was the final trigger. I'd been thinking about this problem for a while, but that conversation today is what made me sit down and start the project.

Why Yet Another Email (and Calendar) App?

I manage technology operations across multiple organizations — Dev 2 Dev Portal LLC, RPG Research, RPG Therapeutics LLC, Practicing Musician SPC, ClimbHigh.AI, and several others. Between these organizations, I deal with dozens of email accounts, numerous calendars, and multiple contact address books, across a mix of Android phones, iOS tablets, Linux and Windows desktops, and macOS laptops. My colleagues and collaborators have similarly varied device ecosystems.

For years, I've been cobbling together combinations of applications to cover my needs. Thunderbird on the desktop. Claws-mail, K-9 Mail (now Thunderbird Android), or others on my phones. Looked at DAVx5 for CalDAV/CardDAV sync on Android. A separate calendar app. A separate contacts app. Nothing on iOS. Nothing that works reliably on all platforms from a single codebase.

I finally got frustrated enough to do something about it.

What This Project Is NOT

Before I go further, I want to be direct about what this project is not, because I've seen too many open-source projects over-promise and under-deliver:

This is not production-ready software. As of this writing, the project is in early pre-alpha. There's a basic prototype running in the Android emulator — the application shell, navigation between email/calendar/contacts/settings, account management, sync controls, theme selection, and notification settings are functional. But the core protocol implementations (IMAP, CalDAV, CardDAV) are still in progress. It's a skeleton with working joints, not a finished body. I'm sharing this now because I believe in building in the open, and because I want community input while the architecture is still taking shape.

This is not a Thunderbird replacement. Thunderbird has decades of development behind it, a large team, and institutional support from MWZLA (the Mozilla subsidiary that manages Thunderbird). I'm one developer with a day job (actually several day jobs). D2D Mail+Cal Client is trying to fill a specific gap that Thunderbird hasn't filled: a single application with email + CalDAV + CardDAV that works across all platforms, including mobile.

This is not backed by venture capital or corporate funding. This is a personal project, hosted by Dev 2 Dev Portal LLC, licensed under AGPL-3.0. If it takes a year or two to reach a usable state, that's the reality of unfunded open-source work. I'll keep making progress as I can, like I do with my other projects — Brain-Computer Interface RPG - BCI RPG, DGPUNET, SIIMPAF, AILCPH, RPEPTFS, RPG AI, NeuroRPG, and many others.

With that said, here's the problem and what I intend to do about it.

The Gap Nobody Has Filled?

As of early 2026, as far as I can find (and not defunct), the open-source ecosystem has some strong individual pieces, but no single (private and non-data-harvester) application that brings email, CalDAV (calendar), and CardDAV (contacts) together across all major platforms. Here's what I found when I did my evaluation:

Thunderbird Desktop (Windows, Linux, macOS) is probably the strongest option we have in open source right now for email + calendar + contacts on the desktop. It supports IMAP, SMTP, CalDAV, and CardDAV. But macOS support has been inconsistent — the Thunderbird team has acknowledged ongoing issues there — and there's no version that runs on mobile with the same capabilities.

Thunderbird Android (formerly K-9 Mail) handles email reasonably well, but as of this writing, it has no CalDAV or CardDAV support. Calendar integration doesn't even have an announced timeline. So it's email-only on Android.

Thunderbird iOS is in early alpha via TestFlight. Email only. No calendar. No contacts. Calendar support isn't on the near-term roadmap.

DAVx5 is an excellent CalDAV and CardDAV sync adapter for Android. But it's Android-only, it requires pairing with separate calendar and contacts apps to actually view and manage the data, and it doesn't exist for iOS, desktop, or web.

Apple Mail, Outlook, Gmail clients — these do support CalDAV and CardDAV to varying degrees. But they're proprietary, closed-source, and increasingly harvest user data — including email content and calendar data — to train AI models. For privacy-conscious individuals and organizations, especially those handling sensitive client data like we do at RPG Therapeutics (healthcare-adjacent therapeutic services) and RPG Research (research involving human subjects), this is a non-starter.

Here's what the landscape actually looks like when you lay it out:

Application	Email	CalDAV	CardDAV	Android	iOS	Linux	macOS	Windows	Web	FOSS	Data Harvesting
Thunderbird Desktop	Yes	Yes	Yes	—	—	Yes	Partial	Yes	—	Yes	No
Thunderbird Android	Yes	—	—	Yes	—	—	—	—	—	Yes	No
Thunderbird iOS	Alpha	—	—	—	Alpha	—	—	—	—	Yes	No
DAVx5	—	Sync	Sync	Yes	—	—	—	—	—	Yes	No*
Apple Mail	Yes	Yes	Yes	—	Yes	—	Yes	—	Yes	No	Yes**
Gmail / Outlook	Yes	Partial	Partial	Yes	Yes	—	—	Yes	Yes	No	Yes
D2D Mail+Cal	Goal	Goal	Goal	Goal	Goal	Goal	Goal	Goal	Goal	Yes	No

*DAVx5 from Bitfire — no, they don't harvest your data. The Infomaniak fork, however, includes analytics trackers. See "Even Open Source Isn't Always What It Seems" below.

**Apple claims to protect user privacy through on-device processing and differential privacy, but they explicitly use on-device analysis of user data to improve Apple Intelligence features — including Writing Tools, Image Playground, and Visual Intelligence. Apple's own legal disclosures acknowledge training data from web crawling, user studies, and other sources. Bloomberg and CNET have reported on Apple's plans to analyze user data on-device for AI training. Siri integration with third-party apps can transmit contextual data to Apple's servers. However much Apple intends to make their data handling "safer," they acknowledge harvesting user data — the privacy protections are a matter of degree and trust in their claims, not an absence of data collection. And the on-device training approach has drawn comparisons to Apple's previously abandoned CSAM detection system, which doesn't exactly inspire confidence.

One glance and the gap is apparent. As far as I've found, there is no single row where a FOSS application fills every column. If I'm wrong and I've missed something, please let me know — I'd genuinely rather use an existing solution than build one from scratch.

I went through this evaluation methodically. I checked every FOSS email client I could find on AlternativeTo, F-Droid, Flathub, and various "awesome" lists on GitHub. The conclusion was the same each time: I couldn't find a single open-source, privacy-respecting application that handles email + calendars + contacts across all major platforms.

Why This Matters Beyond Personal Convenience

This isn't just about my personal workflow frustration, though that's certainly what prompted the project. There are broader issues at play.

Privacy erosion is accelerating. Major email providers are now explicitly using email, calendar, and contacts data to train AI models. Google updated its privacy policy in 2023 to allow broader AI training use of user data. Microsoft's Copilot integrations process email and calendar content. Apple claims better privacy through on-device processing, but they still harvest user data for AI training — they just claim to do it more carefully. And it's proprietary and not independently auditable, so those claims require trust. For organizations handling sensitive data — healthcare, research with human subjects, legal communications, financial records — trusting proprietary clients with that data is increasingly risky.

Vendor lock-in is getting worse, not better. I've written about this problem before in the context of broader IT infrastructure. The email and calendar space has the same dynamics. Once your organization standardizes on Outlook + Exchange or Gmail + Google Workspace, switching becomes painful and expensive. Open standards (IMAP, SMTP, CalDAV, CardDAV) exist precisely to prevent this, but you need clients that actually implement those standards well.

The open-source community deserves better. We have excellent self-hosted mail servers — Stalwart, Dovecot + Postfix, Cyrus IMAP. We have excellent CalDAV/CardDAV servers — SOGo, Radicale, Baikal, Nextcloud. What we're missing is a client that connects to all of these across every device a person might use, without requiring three or four separate apps and platform-specific workarounds.

Even Open Source Isn't Always What It Seems

And here's the thing — even when you find what looks like a good FOSS option, you have to look carefully. The open-source label alone doesn't guarantee your data is being respected.

Take what happened with DAVx5. The legitimate DAVx5 is developed by a small team at Bitfire — genuinely open source, genuinely privacy-respecting, doing honest work trying to make a living while giving back to the community. Then Infomaniak, a large Swiss company, forked DAVx5 and published it on F-Droid using the same name and the same logo — to the point where F-Droid community members reported it was indistinguishable from the original. A user searching F-Droid for "DAVx5" could easily install Infomaniak's version instead of Bitfire's, without realizing it was a different app from a different company.

Why does this matter? Because Infomaniak's version includes Sentry crash reporting and Matomo analytics trackers — F-Droid flags these apps with anti-features for "Tracking — reports your activity" and "Uses or promotes paid network service." The original DAVx5 from Bitfire has neither of these. Someone who specifically chose DAVx5 because they wanted privacy could end up with an analytics-laden fork without knowing the difference, because the name, logo, and F-Droid listing looked identical.

An F-Droid moderator characterized it as a "fastlane metadata mixup" and referenced a merge request to address the issue. Maybe it was unintentional on Infomaniak's part. I'd like to give the benefit of the doubt. But the practical effect is the same: users who thought they were installing a privacy-respecting sync tool got one with analytics tracking instead. And separate concerns have been raised about Infomaniak's public stance on Swiss encryption surveillance legislation, which doesn't exactly inspire confidence about their approach to user privacy.

This kind of thing is exactly why "open source" and "privacy-respecting" need to be treated as two separate questions. A project can be open source and still track you. A project can be open source and still funnel your data somewhere you didn't agree to. The license is necessary but not sufficient. You have to look at what the code actually does, what services it phones home to, and who controls the infrastructure it connects to.

What I'm Building

D2D Mail+Cal Client is a Flutter-based application targeting all major platforms from a single codebase. Here's the current early prototype running in the Android emulator — the Settings screen showing account management, sync controls, and the bottom navigation between Email, Calendar, Contacts, and Settings:

D2D Mail+Cal Client pre-alpha prototype, February 18, 2026. The application shell, navigation, and settings infrastructure are functional. Core protocol implementations (IMAP, CalDAV, CardDAV) are still in progress.

The core feature set:

• Email: IMAP/SMTP with IMAP IDLE push support via the enough_mail library (MPL 2.0 licensed). Auto-discovery of mail server settings. Multiple account support. Aggregated inbox.
• Calendar: Full CalDAV read/write sync with offline support. Using caldav_client as a starting point, with significant extension required for proper RFC 4791 compliance, WebDAV-Sync (RFC 6578), ctag/etag-based change detection, and a robust offline sync engine.
• Contacts: Full CardDAV read/write sync with offline support. This likely requires a custom implementation — as of February 2026, I haven't found a production-ready Dart CardDAV library. Following RFC 6352 with support for both vCard 3.0 and vCard 4.0 (RFC 6350).
• Offline-first architecture: All data syncs to a local database. The app is intended to be fully functional without network connectivity. Sync happens in the background when a connection is available.
• Push notifications without Google or Apple dependency: On Android, using UnifiedPush or foreground service with IMAP IDLE — no Firebase Cloud Messaging (FCM). On iOS, Background App Refresh with local notifications. The goal is that a user can function fully without any third-party push notification service.
• Zero tracking, zero data harvesting, zero telemetry: No analytics. No crash reporting to third parties. No phone-home behavior. All data stays on the user's device and their chosen server. Period.

Why Flutter?

I chose Flutter for a practical reason: it's the most mature framework for building truly cross-platform applications from a single codebase that targets Android, iOS, Linux, macOS, Windows, and Web. I evaluated React Native, Kotlin Multiplatform, and .NET MAUI as alternatives. Flutter's widget rendering approach and its Dart language offer the strongest OOAD (Object-Oriented Analysis and Design) compliance of the options I evaluated, which matters to me — I've spent decades watching projects collapse under the weight of spaghetti code, and I have strong opinions about code quality and as an aside, coder vs. CTO roles.

To be clear, I am not a Dart/Flutter "Fan Boy", I go with what is practical. Unfortunately, since Oracle acquired and ruined much of Java, there hasn't been a good "write once, run anywhere" solution since.

This is the closest so far. It has (many) issues, and I'm nervous about Google's history with projects and communities. But right now, I don't see a better alternative than Dart/Flutter. I have no brand or product loyalty, I focus on what works for the specific and larger goals, based on what is best at the time and can be manageable and scalable over time.

Dart as a language has issues, but it is trying, reputedly, to get to an intended point where it is trying to support clean class hierarchies, strong typing, and separation of concerns in a way that aligns well with how I think about software architecture (OOAD). It's not Java (which I love, at least the pre-Oracle spirit of Java), but it borrows enough of Java's structural strengths while being purpose-built for the UI-heavy cross-platform work this project requires.

Architecture Approach

The application follows a feature-module architecture:

feature_name/
├── data/           # Data sources, repositories, DTOs
├── domain/         # Entities, use cases, repository interfaces
└── presentation/   # Widgets, pages, state management

Domain never imports from data or presentation. Presentation never imports from data. Data implements interfaces defined in domain. One class per file. Single Responsibility Principle throughout. These aren't aspirational goals — they're enforced rules for the project.

State management uses BLoC (Business Logic Component) pattern. The offline-first data flow follows a predictable sequence: UI requests data from use case, use case calls repository, repository checks local database first, returns local data immediately, then syncs with remote server in background, and notifies UI when fresh data arrives.

For conflict resolution (which is inevitable with any sync-capable application), the default follows CalDAV/CardDAV convention: server wins, with an option for the user to manually override individual conflicts. This isn't the most user-friendly default, but it's the safest one, and it's what the protocol specifications expect.

Development Roadmap

The project is phased by platform:

Phase 1 — Mobile (Android & iOS): This is the highest priority because the gap is most severe on mobile. Desktop users at least have Thunderbird. Mobile users don't appear to have anything that combines email + CalDAV + CardDAV in a single FOSS app.

• Milestone 1.1: Core email client (IMAP/SMTP, multi-account, unified inbox, IMAP IDLE push, offline cache)
• Milestone 1.2: CalDAV calendar (discovery, CRUD, recurring events, reminders, offline sync with WebDAV-Sync)
• Milestone 1.3: CardDAV contacts (discovery, CRUD, vCard 3.0/4.0, offline sync)
• Milestone 1.4: Integration and polish (email-to-calendar, iMIP calendar invites in email, contact auto-complete in compose)

Phase 2 — Desktop (Linux, macOS, Windows): Adapt UI for desktop form factors. Multi-pane layouts, keyboard navigation, system tray integration. Distribution via AppImage/Flatpak for Linux, .dmg for macOS, MSIX for Windows.

Phase 3 — Web (Self-Hosted): A self-hosted web interface running on Debian Linux + Nginx + PostgreSQL. WebSocket-based real-time updates. PWA capabilities for limited offline support. No SaaS dependency — you host it yourself.

Server Compatibility

D2D Mail+Cal Client is designed to work with any standards-compliant server. I'm specifically targeting compatibility with self-hosted servers that the open-source community actually uses:

Mail: Stalwart Mail Server, Dovecot + Postfix, Cyrus IMAP, or any RFC-compliant IMAP/SMTP server.

CalDAV/CardDAV: SOGo, Radicale, Baikal, Nextcloud, Stalwart (which also supports CalDAV/CardDAV), or any server compliant with RFC 4791 (CalDAV) and RFC 6352 (CardDAV).

Distribution is planned for direct download, F-Droid (high priority — no Google Play dependency required), Google Play Store, Apple App Store, Flathub, Snap Store, and Microsoft Store.

How to Get Involved

The source code is hosted on our private Gitea instance at git.dev2dev.net/Dev2Dev/d2dmailcalclientflutter_project. I'll be setting up mirrors and contribution guidelines as the project develops.

If you're interested in contributing, the areas where help would be most valuable right now:

As far as I know...

• CardDAV implementation: I haven't found a production-ready Dart CardDAV library. Building a clean, reusable, RFC 6352-compliant CardDAV module would benefit not just this project but the broader Dart/Flutter ecosystem.
• vCard parsing: Similarly, I haven't found a solid vCard 3.0/4.0 parser/generator for Dart — one would be broadly useful.
• CalDAV extension: The existing caldav_client library needs significant work for full RFC 4791 compliance and WebDAV-Sync support.
• Testing against diverse servers: If you run a CalDAV/CardDAV server (SOGo, Radicale, Baikal, Nextcloud, or others), testing interoperability once we have working code would be invaluable.
• UI/UX design: I'm a backend and infrastructure person, not a designer. If someone with UI/UX experience wants to contribute, the application would benefit significantly.

If you know of libraries or options available that are current and viable for Dart/Flutter, for any of these components (or others, or even the entire app), please let me know.

The repository is currently private while the architecture takes shape, but I plan to make a public version available on git.dev2dev.net once it's further along. In the meantime, if you want to follow the project's progress, have a use case you'd like to share, or are interested in contributing, email me directly at hawke@dev2dev.net. Every perspective from someone dealing with the same frustrations helps shape the architecture.

The Bigger Picture

This project fits into a pattern I've followed throughout my career. When the existing tools don't do what I need, and nobody else is building them, I build them myself — or more accurately, I cobble together existing open-source components with the minimum custom glue code needed to fill the gaps. I've documented this approach extensively in my CITO Methodologies article: roughly 80-90% existing open-source solutions, 10-20% custom development to integrate them for the specific use case(s).

The email and calendar space has well-established open standards. The server side is well-served by open-source implementations. What's missing is a client that is genuinely free, genuinely open, genuinely private, and genuinely non-invasive — one that ties it all together across platforms without hidden trackers, without data harvesting, and without corporate interests masquerading behind open-source branding.

That gap — of integrity, ethics, privacy, and control over your own data — is what D2D Mail+Cal Client intends to fill.

Your email is yours. Your calendar is yours. Your contacts are yours. Your data is yours. Full stop.

---

Project Links: - Repository: git.dev2dev.net/Dev2Dev/d2dmailcalclientflutter_project - License: AGPL-3.0 - Author Website: hawkerobinson.com - Dev 2 Dev Portal: dev2dev.net

---

About the Author

W.A. Hawkes-Robinson (known as Hawke Robinson), "The Grandfather of Therapeutic Gaming", serves as CITO at Dev 2 Dev Portal LLC, Practicing Musician SPC, and ClimbHigh.AI. He is the Executive Director and co-founder of the 501(c)3 non-profit RPG Research, founder of RPG Therapeutics LLC, and has been developing software since 1979 — with focus areas including distributed computing, educational technology, therapeutic applications of gaming, and privacy-respecting infrastructure. He has implemented technology infrastructure across 150+ countries for organizations ranging from bootstrapped non-profits to Fortune 50 enterprises.

Contact: hawke@dev2dev.net Website: hawkerobinson.com Tech Blog: techtalkhawke.com LinkedIn: linkedin.com/in/hawkerobinson

---

Version: 2026.02.18-2030