JMAP for Calendars, Contacts and Files Now in Stalwart

Original Article ↗ Hacker News Discussion ↗

JMAP vs existing protocols (IMAP, WebDAV, CalDAV, CardDAV)

  • Many see JMAP as a cleaner, more modern API: fewer round trips, easier batching, one connection for updates across folders, and better fit for web/JS clients.
  • IMAP is criticized as overly stateful, extension-heavy, and awkward (UID quirks, multiple idle connections, weak push story). Others note that with extensions (e.g., NOTIFY, UIDONLY) it’s workable.
  • For calendars/contacts/files, several people describe CalDAV/CardDAV/WebDAV+iCalendar/vCard as extremely complex and painful to implement correctly, especially calendars and time zones.
  • Others push back: these XML/WebDAV-based protocols are widely deployed, battle-tested, and “just work” for common platforms (iOS/Android). They worry JMAP variants will fragment standards without clear user benefit.

Transport, data formats, and protocol design space

  • Long digression on why modern protocols tend to be “JSON over HTTP”:
    • Pro: HTTP/2/3 are already binary; JSON is ubiquitous, easy to debug, compresses well, and there are many libraries. Using HTTP avoids fighting middleboxes and port issues.
    • Con: concern that always layering on HTTP stifles experimentation with new binary protocols; HTTP is a large, complex stack for non-web software; JSON has weak typing (ints, big numbers, binary). Some prefer DER/ASN.1 or CBOR.
  • Several point out that serializers and custom binary protocols introduce their own complexity and lock-in.

Stalwart as an integrated self-hosted stack

  • Enthusiasts like the “one small Rust binary” that provides SMTP/IMAP/JMAP, DAV, spam filtering, DKIM/SPF/DMARC, TLS automation, clustering, search, and multiple storage backends (SQL, RocksDB, S3, filesystem).
  • Users report successful production use and praise flexibility (e.g., S3-compatible object storage, clustering, HA design).
  • Criticisms:
    • Documentation is patchy and sometimes outdated; configuration is split between TOML and a DB; Web UI is too central for people wanting declarative config.
    • Reverse-proxy and multi-service setups (existing webserver, external certs) are confusing; installer appears aimed at “take over the whole box”.
    • Upgrades can include breaking config/DB changes between minor versions, making auto-update risky.
  • Containerization is supported and works well for some, but others avoid it due to disk/overhead on small systems.

Spam filtering and AI/enterprise split

  • Enterprise edition adds AI/LLM-based spam/phishing detection and third‑party AI integrations; some dislike the AI angle, others note these features are optional and paid.
  • Reports on spam filtering are mixed: some find it ineffective and left; others see mostly accurate classification with understandable false positives.

JMAP ecosystem, adoption, and clients

  • JMAP mail is standardized and implemented by several servers (including Fastmail and Cyrus); JMAP contacts and calendars are newer, with Stalwart among the first full implementations.
  • Client support is the main bottleneck: mainstream clients (Apple Mail, Outlook, most mobile apps) and big providers (Gmail, iCloud) do not support JMAP. Current support is mostly niche (e.g., aerc, some web clients) and Fastmail’s own apps.
  • Some argue this makes JMAP a niche IMAP replacement with limited practical impact; others say servers like Stalwart, Mozilla’s planned service, and Nextcloud integration can bootstrap a healthier JMAP ecosystem.
  • There’s interest in using Stalwart as a JMAP “front-end” that syncs from existing IMAP accounts, to let new JMAP clients coexist with legacy providers.

Bigger picture: will users notice?

  • Proponents view JMAP+Stalwart as a path to more consistent, open, and self-hostable “groupware” (mail, calendar, contacts, files, sharing) with modern APIs.
  • Skeptics question whether new protocols help if client UX, email’s inherent limitations, and big-provider dominance remain unchanged.