- Der Open-Source-Kollaborationsserver Stalwart hat nach vier Jahren Entwicklung einen neuen Meilenstein erreicht und JMAP für Kalender, Kontakte sowie Dateispeicherung und -freigabe vollständig implementiert
- Mit diesem Release ist Stalwart der erste Server mit vollständiger Unterstützung der gesamten JMAP-Protokollfamilie und bietet eine integrierte API, die über E-Mail hinaus auf die gesamte Zusammenarbeit ausgeweitet ist
- Über ein einheitliches JSON-basiertes Framework werden die Komplexität und Ineffizienz von WebDAV, CalDAV und CardDAV ersetzt und eine entwicklerfreundliche Struktur geschaffen
- Die neuen Formate JSCalendar und JSContact beseitigen die Komplexität von iCalendar und vCard und bieten ein klares, konsistentes Datenmodell
- Dies steht sinnbildlich für die Weiterentwicklung offener, standardbasierter Kollaborationstechnologien und kündigt eine beschleunigte Innovation im integrierten Ökosystem aus Kalendern, Dateifreigabe und Mail an
Eine neue Generation von Protokollen
- In den vergangenen Jahren hat die IETF die Art und Weise neu definiert, wie E-Mail, Kalender und Kontakte synchronisiert und geteilt werden
- Aufbauend auf dem Erfolg von JMAP for Mail wurden neue Erweiterungsprotokolle für Kalender, Kontakte, Dateien und Freigabe eingeführt
- JMAP for Calendars - die moderne Alternative zu CalDAV und CalDAV Scheduling
- JMAP for Contacts – eine starke Alternative zu CardDAV
- JMAP for File Storage – ersetzt WebDAV-basierte Dateispeicher
- JMAP Sharing – der moderne Nachfolger von WebDAV ACL
- JSCalendar - iCalendar, weiterentwickelt als sauberes JSON-basiertes Format
- JSContact – der modernisierte JSON-basierte Nachfolger von vCard
- Diese Standards bieten ein integriertes und elegantes Ökosystem als Ersatz für fragmentierte WebDAV-basierte Technologien
- Sie lösen Kompatibilitätsprobleme aus Jahrzehnten und vereinfachen Kollaborationsfunktionen mit einem einheitlichen Datenmodell
Die Grenzen bestehender Technologien
- WebDAV, CalDAV und CardDAV werden seit Langem stabil genutzt, sind aber durch ihr XML-basiertes Design übermäßig wortreich und inkonsistent
- Daten sind auf HTTP-Header, XML-Payloads, iCalendar-Daten und weitere Stellen verteilt, wodurch häufig Interoperabilitätsprobleme zwischen Clients und Servern entstehen
- Auch iCalendar und vCard tragen technische Altlasten aus Jahrzehnten mit sich
- Es gibt viele selten genutzte oder veraltete Eigenschaften, und abweichende Implementierungen je nach Version machen komplexe Parsing-Logik erforderlich
- Diese strukturelle Komplexität erschwert Wartung und Skalierbarkeit und ist für moderne Kollaborationsumgebungen ungeeignet
JMAP für moderne Anforderungen
- Das JMAP-Protokoll wurde ursprünglich als effizientes und einfaches Mail-Protokoll entwickelt, um IMAP und SMTP zu ersetzen
- Auf Basis von JSON over HTTPS vereint es Klarheit und Netzwerkeffizienz
- Mit der Einführung von JMAP for Calendars, Contacts, Files und Sharing wird dieselbe Designphilosophie nun auf die gesamte Zusammenarbeit ausgeweitet
- Es bietet eine integrierte und konsistente API für Mail, Kalender, Kontakte, Dateien und freigegebene Ressourcen
- JSCalendar und JSContact bilden iCalendar und vCard als JSON-basierte Formate neu ab
- Sie entfernen unnötige Eigenschaften und liefern ein klares, konsistentes Datenmodell
- Sie sind leicht für Menschen lesbar, entwicklerfreundlich, effizient zu parsen und für moderne Anwendungen optimiert
- Die Kombination aus JMAP und diesen neuen Datenmodellen ermöglicht es, Kalender, Kontaktverwaltung und Dateifreigabe schneller und zuverlässiger umzusetzen
Die Bedeutung dieses Releases
- Dieses Release ist mehr als nur eine Funktionserweiterung; es markiert einen Wendepunkt im Design von Groupware-Protokollen
- Entwickler und Organisationen können Mail, Kontakte, Kalender und freigegebene Ressourcen auf einem einheitlichen JSON-basierten Framework aufbauen
- Die Einfachheit und Vorhersehbarkeit von JMAP helfen Clients und Servern, sich stärker auf Funktionen und Nutzererlebnis statt auf Protokollverarbeitung zu konzentrieren
- Dadurch werden weniger Interoperabilitätsprobleme, höhere Entwicklungsgeschwindigkeit und beschleunigte Innovation erwartet
- Das fördert Standardisierung und Effizienzsteigerung in Kollaborationssoftware insgesamt
Client-Unterstützung und Ausbau des Ökosystems
- Stalwart ist derzeit der erste Server mit vollständiger Unterstützung der gesamten JMAP-Protokollfamilie, während die Client-Unterstützung noch in einer frühen Phase ist
- Dennoch übernehmen bereits mehrere Projekte die neuen Standards
- Mailtemi, Parula und OpenCloud entwickeln bereits Clients für JMAP Calendars, Contacts und File Storage
- Das Ökosystem wächst schnell, und je mehr Entwickler die Eleganz und Leistungsfähigkeit von JMAP direkt erleben, desto eher ist eine rasche Verbreitung zu erwarten
2 Kommentare
Klingt gut!!
Hacker-News-Kommentare
Ich denke, JMAP ist ein sehr gutes Protokoll für den Bau von E-Mail-Clients
Ich möchte Self-Hosting zwar vermeiden, aber es wäre interessant, Stalwart als Server-Komponente für einen Client zu verwenden, bestehende IMAP-Daten zu synchronisieren und dann über die JMAP-API darauf zuzugreifen
Ich habe gehört, dass so etwas wie IMAP-zu-IMAP-Synchronisierung möglich ist, und frage mich, ob das schon jemand mit Stalwart ausprobiert hat
Wenn so ein Ansatz möglich wird, könnte man auf bestehende IMAP-Postfächer per JMAP zugreifen, was die Entwicklung einer neuen Generation von E-Mail-Clients fördern dürfte
Stalwart ist wirklich wunderschön strukturierte Software
Beeindruckend ist, wie dort Schritt für Schritt Vertrauen aufgebaut und die Reife des Produkts kontinuierlich erhöht wurde
Außerdem ist es erstaunlich, dass das Ganze fast von einer einzigen Person vorangetrieben wurde
GitHub-Mitwirkendengrafik
Wenn man ein entferntes IMAP-Konto regelmäßig mit dem lokalen IMAP-Server von Stalwart synchronisiert, stellt Stalwart dies intern umgewandelt als JMAP bereit
Zuerst dachte ich, dafür müsse man über maildir gehen, aber mit IMAP-↔-IMAP allein scheint es gut machbar zu sein
Alles, was ich bisher gefunden habe, war zu teuer, deshalb freue ich mich über diese Entwicklung
Es gibt noch kein Ergebnis, aber ich denke weiter darüber nach
Da Stalwart faktisch die erste Server-Implementierung von JMAP ist, gibt es jetzt überhaupt erst einen Grund, Clients dafür zu entwickeln
Übrigens soll auch Mozillas neuer Mail-Dienst JMAP verwenden, was für ordentlich Schub sorgen dürfte
Früher habe ich Groupware wie Nextcloud oder SoGo ausprobiert, war aber enttäuscht
Jetzt arbeitet Nextcloud jedoch mit Stalwart zusammen, und Opencloud sowie Mozilla/Thunderbird integrieren ebenfalls JMAP, was Hoffnung macht
Besonders interessant ist auch Thunderbirds Webmail-Projekt Stormbox
Gerade jetzt ist der Zeitpunkt perfekt, weil die Bewegung weg von Big Tech stark ist
Cyrus unterstützte nur JMAP-Mail
Damit ist nun Synchronisierung zwischen CalDAV, JMAP und Dateisystem möglich
Ich benutze den Client aerc
Dinge wie Dateifreigabe, Groupware, Mail und Kalender ließen sich vielleicht auch effizienter ohne JSON-Overhead entwerfen
Trotzdem wird es sicher gute Gründe für ein HTTP-basiertes Design geben
Die meisten frühen Internetprotokolle wurden textbasiert über Telnet entwickelt
HTTP/3 ist seinem Wesen nach ein Binärprotokoll, und JSON ist strukturiert und gut komprimierbar, also in der Praxis ziemlich effizient
„JSON over HTTP“ ist gegenüber „benutzerdefiniertem Text über Telnet“ eine subtile, aber eindeutige Verbesserung
Selbst wenn man Frameworks wie capnproto, grpc oder ASN.1 verwendet, bringt jedes davon seine eigene Komplexität mit
JSON ist einfach und hat klare Grenzen, wodurch es leicht zu handhaben ist
Dagegen führen implementierungsabhängige Designs wie die Protokolle von Microsoft Exchange langfristig zu Problemen
Je nach Fall kann auch ein anderes Protokoll als TCP besser sein
Persönlich mag ich JSON nicht und halte DER-Format für besser
Auch „Small Web“-Protokolle wie Gemini oder Scorpion finde ich interessant
Für die Kompatibilität mit Web-Clients ist HTTP sogar praktisch die einzige Wahl
Ich sehe kaum Vorteile darin, HTTP nicht zu verwenden
Wenn man statt JSON CBOR nutzt, kann auch die Nutzlast binär sein
HTTP ist ein Protokoll für state transfer und daher gut für Synchronisierung geeignet
Mit der Braid-Erweiterung lässt es sich sogar zu einem Protokoll für state synchronization erweitern
Ich arbeite am Braid-Projekt mit
Mail wird bereits unterstützt, aber derzeit braucht man zusätzlich noch CardDAV und CalDAV
Der vor 10 Jahren geschriebene
caldav_sync-Code läuft immer nochKürzlich wurde die Logik zur Erzeugung von objectid verbessert, um IDs kleiner und besser sortierbar zu machen
Als Nächstes sollen Kalender und Kontakte auf die aktuelle JMAP-Spezifikation aktualisiert werden
Das Dateisystem wird wohl noch etwas länger dauern
Siehe das Entwurfsdokument
Contacts wurde vor 10 Monaten als RFC 9610 verabschiedet
Auch ist nicht klar, welches Problem es gegenüber bestehenden Lösungen eigentlich konkret löst
Große Clients wie Apple Mail, Thunderbird oder Outlook müssen es unterstützen
Ich hätte erwartet, dass kleinere Clients wie Canary oder Spark es als Unterscheidungsmerkmal einführen, aber überraschenderweise tun sie das nicht
Das neue Outlook speichert alle Daten in Azure und kommuniziert mit den eigentlichen Servern nur noch über einen Proxy
Dass es JMAP unterstützt, ist so gut wie ausgeschlossen
(Das soll keine Verteidigung von IMAP sein)
Wenn Gmail oder iCloud es nicht unterstützen, bringt es wenig, einen Client dafür zu bauen
Dual-Support wäre zwar möglich, aber der Markt wäre klein
Aber dafür gibt es noch viele offene „if“
Es fühlt sich an, als beginne eine neue Ära mit einem vollständig integrierten Server
Maddy ist auch okay, aber die Wartung dort ist weniger aktiv
Es gibt keine Dokumentation, in der man Optionen, Standardwerte und ihre Beziehungen auf einen Blick sehen kann
Die Konfiguration über die Web-UI ist zwar möglich, kollidiert aber mit deklarativen Deployments
Wenn die
.toml-Datei schreibgeschützt ist, tritt ein Fehler aufAbgesehen von FastMail oder Topicbox scheint es da nicht viel zu geben
Ich brauche etwas, das sich wie Roundcube oder Wildduck per HTTPS selbst hosten lässt
Abgesehen von „neu in Rust geschrieben“ sehe ich kein klares Unterscheidungsmerkmal
Ohne gute MUAs ist fraglich, ob JMAP überhaupt hilfreich sein wird
Die Server-Seite ist bereits gelöst, aber bei den Clients herrscht Stillstand
Nicht einmal die Funktionen von IMAP4 sind größtenteils vollständig umgesetzt, und auch Sieve-Clients sind miserabel
Dovecot unterstützt noch immer nicht einmal UTF-8 vollständig
Projekte wie Stalwart versuchen, solche Legacy-Grenzen zu überwinden
Auch bei den Clients gab es Fortschritte, etwa mit Apple Mail
Es bringt nichts, wenn sich nur eine Seite weiterentwickelt
Jetzt, da es einen guten Server gibt, fehlen nur noch gute Clients
Nylas ist leistungsfähig, aber teuer
Im großen Maßstab können $1.50 pro Konto und Monat die SaaS-Marge spürbar beeinflussen
Für Echtzeit-E-Mail-Analyse oder den Bau eigener UIs ist es aber sehr nützlich