- El servidor de colaboración de código abierto Stalwart alcanzó un nuevo hito tras 4 años de desarrollo al implementar por completo JMAP para calendarios, contactos, almacenamiento y compartición de archivos
- Con este lanzamiento, Stalwart se convirtió en el primer servidor en soportar por completo toda la familia de protocolos JMAP, ofreciendo una API unificada que va más allá del correo y se expande a toda la colaboración
- A través de un marco único basado en JSON, reemplaza la complejidad e ineficiencia de WebDAV, CalDAV y CardDAV, con una estructura amigable para desarrolladores
- Los nuevos formatos JSCalendar y JSContact eliminan la complejidad de iCalendar y vCard, y ofrecen un modelo de datos claro y consistente
- Esto simboliza la evolución de la tecnología de colaboración basada en estándares abiertos y anticipa una aceleración de la innovación en el ecosistema integrado de calendarios, compartición de archivos y correo
Una nueva generación de protocolos
- En los últimos años, la IETF ha estado redefiniendo la forma en que se sincronizan y comparten el correo, los calendarios y los contactos
- Sobre la base del éxito de JMAP for Mail, se introdujeron nuevos protocolos de extensión para calendarios, contactos, archivos y compartición
- JMAP for Calendars - una alternativa moderna a CalDAV y a la programación de CalDAV
- JMAP for Contacts – una sólida alternativa a CardDAV
- JMAP for File Storage – reemplaza el almacenamiento de archivos basado en WebDAV
- JMAP Sharing – el sucesor moderno de los ACL de WebDAV
- JSCalendar - la evolución de iCalendar con una base JSON limpia
- JSContact – el sucesor modernizado de vCard basado en JSON
- Estos estándares ofrecen un ecosistema unificado y elegante que sustituye las tecnologías fragmentadas basadas en WebDAV
- Resuelven décadas de problemas de compatibilidad y simplifican las funciones de colaboración con un único modelo de datos
Los límites de las tecnologías existentes
- WebDAV, CalDAV y CardDAV se han usado de forma estable durante mucho tiempo, pero su diseño basado en XML es demasiado verboso y poco consistente
- Como los datos están dispersos entre encabezados HTTP, cargas XML, datos iCalendar y otros lugares, con frecuencia surgen problemas de interoperabilidad entre clientes y servidores
- iCalendar y vCard también arrastran décadas de deuda técnica
- Tienen muchas propiedades poco usadas u obsoletas, y las implementaciones varían según la versión, lo que exige lógica de parsing compleja
- Esta complejidad estructural dificulta el mantenimiento y la escalabilidad, y resulta poco adecuada para los entornos modernos de colaboración
La llegada de JMAP para las necesidades modernas
- El protocolo JMAP fue desarrollado originalmente como un protocolo eficiente y simple de transporte de correo para reemplazar IMAP y SMTP
- Basado en JSON sobre HTTPS, ofrece claridad y eficiencia de red al mismo tiempo
- Ahora, con la incorporación de JMAP for Calendars, Contacts, Files y Sharing, la misma filosofía de diseño se expande a toda la colaboración
- Ofrece una API unificada y consistente para correo, calendarios, contactos, archivos y recursos compartidos
- JSCalendar y JSContact reconstruyen iCalendar y vCard existentes como formatos basados en JSON
- Eliminan propiedades innecesarias y proporcionan un modelo de datos claro y consistente
- Son fáciles de leer para humanos, amigables para desarrolladores y más eficientes de parsear, por lo que están optimizados para aplicaciones modernas
- La combinación de JMAP con estos nuevos modelos de datos permite implementar calendarios, gestión de contactos y compartición de archivos de forma más rápida y confiable
El significado de este lanzamiento
- Este lanzamiento va más allá de añadir funciones: representa un punto de inflexión en la forma de diseñar protocolos de groupware
- Desarrolladores y organizaciones ahora pueden construir correo, contactos, calendarios y recursos compartidos sobre un único marco basado en JSON
- La simplicidad y previsibilidad de JMAP ayuda a que clientes y servidores se concentren en las funciones y la experiencia de usuario, en lugar del procesamiento del protocolo
- Como resultado, se espera una reducción de problemas de interoperabilidad, mayor velocidad de desarrollo y aceleración de la innovación
- Esto puede impulsar la estandarización y mejora de eficiencia en todo el software de colaboración
Soporte de clientes y expansión del ecosistema
- Stalwart es actualmente el primer servidor en soportar por completo toda la familia de protocolos JMAP, aunque el soporte del lado cliente sigue en una etapa inicial
- Sin embargo, varios proyectos ya están adoptando los nuevos estándares
- Mailtemi, Parula y OpenCloud ya están desarrollando clientes para JMAP Calendars, Contacts y File Storage
- El ecosistema está creciendo rápidamente y, a medida que los desarrolladores experimenten directamente la elegancia y potencia de JMAP, se espera una expansión acelerada
2 comentarios
¡Qué bien!!
Comentarios en Hacker News
Creo que JMAP es un protocolo muy bueno para crear clientes de correo
Preferiría evitar el self-hosting, pero sería interesante usar Stalwart como componente de servidor para un cliente, sincronizar datos IMAP existentes y acceder a ellos mediante la API de JMAP
He oído que algo como sincronización IMAP a IMAP podría funcionar, y me pregunto si alguien ya lo ha intentado con Stalwart
Si este enfoque es viable, permitiría acceder a buzones IMAP existentes mediante JMAP, lo que podría impulsar el desarrollo de una nueva generación de clientes de correo
Stalwart es realmente un software bellamente estructurado
Impresiona cómo ha ido ganando confianza y madurez de forma gradual
Además, sorprende que haya sido impulsado casi por un solo desarrollador
Gráfico de contribuidores en GitHub
Si sincronizas periódicamente un IMAP remoto con el servidor IMAP local de Stalwart, Stalwart lo convierte internamente a JMAP y lo expone así
Al principio pensé que habría que pasar por una etapa intermedia de maildir, pero parece que con IMAP ↔ IMAP basta
Todo lo que había encontrado hasta ahora era demasiado caro, así que este avance me da gusto
Aún no tengo nada hecho, pero sigo dándole vueltas
Stalwart es prácticamente la primera implementación de servidor de JMAP, así que ahora sí existe una razón para crear clientes
Por cierto, el nuevo servicio de correo de Mozilla también planea usar JMAP, así que podría darle un gran impulso
Antes probé groupware como Nextcloud o SoGo, pero me decepcionaron
Pero ahora que Nextcloud está colaborando con Stalwart, y Opencloud y Mozilla/Thunderbird también están integrando JMAP, tengo expectativas
En especial, también me parece interesante el proyecto de webmail Stormbox de Thunderbird
Ahorita además hay una fuerte tendencia a alejarse del Big Tech, así que el momento es perfecto
Cyrus solo soportaba correo JMAP
Ahora es posible sincronizar entre CalDAV, JMAP y el sistema de archivos
Yo uso el cliente aerc
Cosas como compartir archivos, groupware, correo y calendario quizá podrían diseñarse de forma más eficiente sin la sobrecarga de JSON
Aun así, supongo que hay buenas razones para basarse en HTTP
La mayoría de los primeros protocolos de internet se construyeron sobre Telnet basado en texto
HTTP/3 es esencialmente un protocolo binario, y JSON es estructurado y se comprime bien, así que en la práctica resulta bastante eficiente
“JSON over HTTP” es una mejora sutil, pero real, frente a “texto personalizado sobre telnet”
Incluso usando frameworks como capnproto, grpc o ASN.1, cada uno trae su propia complejidad
JSON es simple y sus límites son claros, así que es fácil de manejar
En cambio, los diseños atados a una implementación, como los protocolos de Microsoft Exchange, acaban generando problemas a largo plazo
Dependiendo del caso, quizá otro protocolo distinto de TCP sea mejor
Personalmente no me gusta JSON y creo que el formato DER sería mejor
También me parecen interesantes protocolos de “small web” como Gemini y Scorpion
De hecho, en términos de compatibilidad con clientes web, HTTP es prácticamente la única opción
No veo casi ninguna ventaja en no usar HTTP
Si usas CBOR en lugar de JSON, el payload también puede ser binario
HTTP es un protocolo de transferencia de estado (state transfer), así que sirve bien para sincronización
Si además le agregas la extensión Braid, puede ampliarse a un protocolo de sincronización de estado (state synchronization)
Trabajo en el proyecto Braid
El correo ya está soportado, pero todavía hay que seguir usando CardDAV/CalDAV en paralelo
Un código
caldav_syncescrito hace 10 años sigue funcionandoRecientemente mejoraron la lógica de generación de objectid para reducir el tamaño de los IDs y mejorar su ordenabilidad
Ahora planean actualizar calendarios y contactos a la especificación más reciente de JMAP
El sistema de archivos probablemente tardará un poco más
Ver el documento en borrador
Contacts fue aprobado hace 10 meses como RFC 9610
Tampoco está claro qué problema resuelve frente a las soluciones existentes
Necesita que clientes importantes como Apple Mail, Thunderbird y Outlook lo soporten
Incluso clientes más pequeños como Canary o Spark podrían adoptarlo como punto de diferenciación, pero curiosamente no lo hacen
El nuevo Outlook guarda todos los datos en Azure y se comunica con el servidor real por medio de un proxy
Es casi imposible que llegue a soportar JMAP
(No es que esté defendiendo IMAP)
Si Gmail o iCloud no lo soportan, crear clientes tendría poco sentido
El soporte dual sería posible, pero el mercado sería reducido
Pero para eso todavía hay muchos “if” pendientes
Da la sensación de que se abrió una nueva era con un servidor totalmente integrado
Maddy también está bien, pero su mantenimiento es menos activo
No hay una documentación donde puedas ver de un vistazo las opciones, valores predeterminados y relaciones entre ellas
La configuración desde la Web UI es posible, pero choca con los despliegues declarativos
Si el archivo
.tomles de solo lectura, da errorFuera de FastMail o Topicbox, no hay mucho
Hace falta algo que pueda self-hostearse por HTTPS como Roundcube o Wildduck
Más allá de “está reescrito en Rust”, no parece haber una diferenciación tan evidente
Sin un buen MUA (cliente de correo), no estoy seguro de que JMAP ayude mucho
El servidor ya está resuelto, pero los clientes están estancados
Ni siquiera se ha implementado la mayoría de las funciones de IMAP4, y los clientes de Sieve también son bastante malos
Dovecot todavía no soporta UTF-8 por completo
Proyectos como Stalwart son intentos de superar esas limitaciones heredadas
Y del lado del cliente también ha habido mejoras, como Apple Mail
No sirve de mucho que avance solo uno de los dos
Ahora que ya existe un buen servidor, lo que falta es un buen cliente
Nylas es potente, pero caro
A gran escala, cuesta $1.50 al mes por cuenta, así que puede afectar el margen de un SaaS
Aun así, es muy útil para análisis de correo en tiempo real o para construir una UI personalizada