- Le serveur collaboratif open source Stalwart franchit une nouvelle étape après 4 ans de développement avec une implémentation complète de JMAP pour les calendriers, les contacts, le stockage et le partage de fichiers
- Avec cette version, Stalwart devient le premier serveur à prendre entièrement en charge l’ensemble de la famille de protocoles JMAP, en proposant une API unifiée qui dépasse l’e-mail pour couvrir l’ensemble de la collaboration
- Grâce à un framework unique fondé sur JSON, il remplace la complexité et l’inefficacité de WebDAV, CalDAV et CardDAV par une structure pensée pour les développeurs
- Les nouveaux formats JSCalendar et JSContact éliminent la complexité de iCalendar et vCard et fournissent un modèle de données clair et cohérent
- Cela symbolise l’évolution des technologies de collaboration fondées sur des standards ouverts et annonce une accélération de l’innovation dans l’écosystème unifié du calendrier, du partage de fichiers et de la messagerie
Une nouvelle génération de protocoles
- Ces dernières années, l’IETF redéfinit la manière de synchroniser et de partager les e-mails, calendriers et contacts
- Sur la base du succès de JMAP for Mail, de nouveaux protocoles d’extension ont été introduits pour les calendriers, les contacts, les fichiers et le partage
- JMAP for Calendars - une alternative moderne à CalDAV et à la planification CalDAV
- JMAP for Contacts – une alternative robuste à CardDAV
- JMAP for File Storage – remplace le stockage de fichiers basé sur WebDAV
- JMAP Sharing – le successeur moderne des ACL WebDAV
- JSCalendar - iCalendar évolué vers un format JSON plus propre
- JSContact – le successeur modernisé de vCard fondé sur JSON
- Ces standards offrent un écosystème unifié et élégant qui remplace les technologies fragmentées basées sur WebDAV
- Ils résolvent des décennies de problèmes de compatibilité et simplifient les fonctions de collaboration avec un modèle de données unique
Les limites des technologies existantes
- WebDAV, CalDAV et CardDAV sont utilisés de manière stable depuis longtemps, mais leur conception fondée sur XML les rend excessivement verbeux et peu cohérents
- Les données étant dispersées entre les en-têtes HTTP, les charges utiles XML, les données iCalendar et d’autres emplacements, les problèmes d’interopérabilité entre clients et serveurs sont fréquents
- iCalendar et vCard portent eux aussi une dette technique accumulée sur plusieurs décennies
- De nombreuses propriétés sont peu utilisées ou abandonnées, et les implémentations diffèrent selon les versions, ce qui impose une logique de parsing complexe
- Cette complexité structurelle nuit à la maintenance et à l’extensibilité, et n’est plus adaptée aux environnements collaboratifs modernes
L’arrivée de JMAP pour répondre aux besoins modernes
- Le protocole JMAP a été initialement développé comme un protocole de messagerie efficace et simple destiné à remplacer IMAP et SMTP
- Basé sur JSON over HTTPS, il apporte à la fois clarté et efficacité réseau
- Avec l’introduction de JMAP for Calendars, Contacts, Files et Sharing, la même philosophie de conception s’étend désormais à l’ensemble de la collaboration
- Il fournit une API unifiée et cohérente pour la messagerie, les calendriers, les contacts, les fichiers et les ressources partagées
- JSCalendar et JSContact reconstruisent iCalendar et vCard sous forme de formats fondés sur JSON
- Ils éliminent les propriétés inutiles et fournissent un modèle de données clair et cohérent
- Ils sont faciles à lire pour les humains, pensés pour les développeurs, efficaces à parser et optimisés pour les applications modernes
- La combinaison de JMAP avec ces nouveaux modèles de données permet d’implémenter le calendrier, la gestion des contacts et le partage de fichiers de manière plus rapide et plus fiable
Ce que signifie cette version
- Cette version ne se limite pas à l’ajout de fonctionnalités : elle marque un tournant dans la conception des protocoles de groupware
- Les développeurs et les organisations peuvent désormais construire messagerie, contacts, calendriers et ressources partagées sur un framework unique fondé sur JSON
- La simplicité et la prévisibilité de JMAP permettent aux clients et aux serveurs de se concentrer sur les fonctionnalités et l’expérience utilisateur plutôt que sur le traitement du protocole
- On peut donc s’attendre à une réduction des problèmes d’interopérabilité, à une accélération du développement et à une innovation plus rapide
- C’est aussi un levier pour améliorer la standardisation et l’efficacité de l’ensemble des logiciels collaboratifs
Support client et expansion de l’écosystème
- Stalwart est actuellement le premier serveur à prendre entièrement en charge l’ensemble de la famille de protocoles JMAP, même si le support côté client en est encore à ses débuts
- Cependant, plusieurs projets ont déjà commencé à adopter ces nouveaux standards
- Mailtemi, Parula et OpenCloud développent déjà des clients JMAP Calendars, Contacts et File Storage
- L’écosystème croît rapidement, et à mesure que les développeurs expérimentent directement l’élégance et la puissance de JMAP, une adoption rapide est attendue
2 commentaires
C'est bien !!
Discussion sur Hacker News
Je pense que JMAP est un très bon protocole pour créer des clients mail
Je préférerais éviter l’auto-hébergement, mais il serait intéressant d’utiliser Stalwart comme composant serveur côté client pour synchroniser des données IMAP existantes et y accéder via l’API JMAP
J’ai entendu dire qu’une approche du type synchronisation IMAP-vers-IMAP était possible, donc je me demande si quelqu’un l’a déjà essayée avec Stalwart
Si cette approche devient viable, elle permettrait d’accéder à des boîtes mail IMAP existantes via JMAP, ce qui pourrait favoriser le développement d’une nouvelle génération de clients mail
Stalwart est vraiment un logiciel magnifiquement structuré
Il est impressionnant de voir à quel point le projet a gagné en maturité progressivement tout en inspirant confiance
Et le fait qu’il ait été porté presque entièrement par un seul développeur est remarquable
Graphique des contributeurs GitHub
Il suffit de synchroniser périodiquement l’IMAP distant vers le serveur IMAP local de Stalwart, puis Stalwart l’expose en interne sous forme de JMAP
Au départ, je pensais qu’il faudrait passer par une étape maildir, mais il semble qu’un simple IMAP ↔ IMAP suffise
Jusqu’ici, tout ce que j’avais trouvé était trop cher, donc cette avancée fait plaisir
Je n’ai encore rien produit, mais j’y réfléchis toujours
Stalwart est de fait la première implémentation serveur de JMAP, donc il y a désormais une vraie raison de créer des clients
À noter que le nouveau service mail de Mozilla devrait lui aussi utiliser JMAP, ce qui pourrait lui donner un gros élan
Avant, j’avais essayé des groupwares comme Nextcloud ou SoGo, mais j’en avais été déçu
Maintenant que Nextcloud collabore avec Stalwart, et qu’Opencloud ainsi que Mozilla/Thunderbird intègrent JMAP, je suis optimiste
Le projet de webmail Thunderbird Stormbox est particulièrement intéressant à suivre
Avec la volonté actuelle de s’éloigner de la Big Tech, le timing est parfait
Cyrus ne prenait en charge que le mail JMAP
Il est maintenant possible de synchroniser entre CalDAV, JMAP et le système de fichiers
J’utilise pour ma part le client aerc
Des choses comme le partage de fichiers, le groupware, le mail ou le calendrier pourraient peut-être être conçues de manière plus efficace, sans la surcharge JSON
Cela dit, il doit bien y avoir des raisons à ce choix d’architecture fondé sur HTTP
La plupart des premiers protocoles d’Internet ont été conçus au-dessus de Telnet en mode texte
HTTP/3 est fondamentalement un protocole binaire, et JSON est structuré et se compresse bien, donc en pratique c’est plutôt efficace
« JSON over HTTP » est une amélioration subtile mais réelle par rapport à « custom text over telnet »
Même avec des frameworks comme capnproto, grpc ou ASN.1, chacun apporte sa propre complexité
JSON est simple, ses limites sont claires et il est facile à manipuler
À l’inverse, des conceptions dépendantes de l’implémentation comme les protocoles Microsoft Exchange créent des problèmes sur le long terme
Dans certains cas, un autre protocole que TCP peut être préférable
Personnellement, je n’aime pas JSON et je pense que le format DER est meilleur
Les protocoles « small web » comme Gemini ou Scorpion sont aussi intéressants
En réalité, du point de vue de la compatibilité avec les clients web, HTTP est le seul choix possible
Je vois très peu d’avantages à ne pas utiliser HTTP
En utilisant CBOR au lieu de JSON, la charge utile peut elle aussi être binaire
HTTP est un protocole de transfert d’état (state transfer), donc bien adapté à la synchronisation
En y ajoutant l’extension Braid, on peut l’étendre à un protocole de synchronisation d’état (state synchronization)
Je travaille sur le projet Braid
Le mail est déjà pris en charge, mais il faut encore utiliser CardDAV/CalDAV en parallèle
Du code
caldav_syncécrit il y a 10 ans tourne encoreRécemment, ils ont amélioré la logique de génération des objectid pour réduire la taille des ID et améliorer leur triabilité
L’objectif est maintenant de mettre à jour le calendrier et les contacts vers la dernière spécification JMAP
Le système de fichiers prendra probablement un peu plus de temps
Voir le document de brouillon
Contacts a été approuvé il y a 10 mois sous la forme de la RFC 9610
Et il n’est pas encore très clair quel problème il résout par rapport aux solutions existantes
Il faudrait que des clients majeurs comme Apple Mail, Thunderbird ou Outlook le prennent en charge
On pourrait aussi imaginer que des clients plus modestes comme Canary ou Spark l’adoptent comme élément différenciant, mais étonnamment ce n’est pas le cas
Le nouvel Outlook stocke toutes les données dans Azure et communique avec les vrais serveurs via un proxy
Il y a donc très peu de chances qu’il prenne en charge JMAP
(Ce n’est pas pour autant une défense d’IMAP)
Si Gmail ou iCloud ne le prennent pas en charge, créer des clients a peu d’intérêt
Un double support reste possible, mais le marché est étroit
Mais pour l’instant, cela dépend encore de beaucoup de conditions
C’est un serveur entièrement intégré, et on a l’impression d’entrer dans une nouvelle ère
Maddy est correct aussi, mais son maintien semble moins actif
Il n’existe pas de documentation permettant de voir d’un coup d’œil les options, leurs valeurs par défaut et leurs interactions
La configuration via l’interface web est possible, mais elle entre en conflit avec des déploiements déclaratifs
Si le fichier
.tomlest en lecture seule, cela provoque une erreurÀ part FastMail ou Topicbox, il n’y a pas grand-chose
Il faudrait quelque chose d’auto-hébergeable en HTTPS comme Roundcube ou Wildduck
En dehors du fait que « c’est réécrit en Rust », je ne vois pas de différence marquante
En l’absence d’un bon MUA (client mail), je me demande à quel point JMAP peut réellement aider
Le serveur est peut-être déjà un problème résolu, mais les clients stagnent
Même les fonctionnalités d’IMAP4 ne sont en grande partie pas implémentées, et les clients Sieve sont médiocres
Dovecot ne prend toujours pas parfaitement en charge l’UTF-8
Des projets comme Stalwart cherchent précisément à dépasser ces limitations héritées
Les clients ont eux aussi progressé dans certains cas, comme Apple Mail
Faire avancer l’un sans l’autre n’a pas beaucoup de sens
Maintenant qu’un bon serveur existe, il reste à avoir de bons clients
Nylas est puissant, mais cher
À grande échelle, c’est 1,50 $ par compte et par mois, ce qui peut peser sur les marges d’une offre SaaS
Cela reste néanmoins très utile pour l’analyse d’e-mails en temps réel ou la construction d’interfaces personnalisées