JMAP para calendário, contatos e arquivos é adicionado ao Stalwart

• O servidor de colaboração open source Stalwart atingiu um novo marco ao implementar completamente o JMAP para calendário, contatos, armazenamento e compartilhamento de arquivos após 4 anos de desenvolvimento
• Com este lançamento, o Stalwart se tornou o primeiro servidor a oferecer suporte completo a toda a família de protocolos JMAP, fornecendo uma API unificada que vai além do e-mail e se estende por toda a colaboração
• Por meio de uma estrutura única baseada em JSON, substitui a complexidade e a ineficiência de WebDAV, CalDAV e CardDAV, oferecendo uma arquitetura amigável para desenvolvedores
• Os novos formatos JSCalendar e JSContact eliminam a complexidade de iCalendar e vCard e fornecem um modelo de dados claro e consistente
• Isso simboliza a evolução das tecnologias de colaboração baseadas em padrões abertos e sinaliza uma aceleração da inovação no ecossistema integrado de calendário, compartilhamento de arquivos e e-mail no futuro

---

Uma nova geração de protocolos

• Nos últimos anos, a IETF vem redefinindo a forma de sincronizar e compartilhar e-mails, calendários e contatos
  • Com base no sucesso do já existente JMAP for Mail, foram introduzidos novos protocolos de extensão para calendário, contatos, arquivos e compartilhamento
  • JMAP for Calendars - alternativa moderna ao CalDAV e ao agendamento do CalDAV
  • JMAP for Contacts – alternativa robusta ao CardDAV
  • JMAP for File Storage – substitui o armazenamento de arquivos baseado em WebDAV
  • JMAP Sharing – sucessor moderno do WebDAV ACL
  • JSCalendar - evolução limpa do iCalendar baseada em JSON
  • JSContact – sucessor modernizado do vCard baseado em JSON
• Esses padrões oferecem um ecossistema unificado e elegante para substituir as tecnologias fragmentadas baseadas em WebDAV
  • Resolvem décadas de problemas de compatibilidade e simplificam os recursos de colaboração com um modelo de dados único

Limitações das tecnologias existentes

• WebDAV, CalDAV e CardDAV são usados de forma estável há muito tempo, mas, por causa de seu design baseado em XML, são excessivamente verbosos e pouco consistentes
  • Como os dados ficam espalhados entre cabeçalhos HTTP, payloads XML, dados iCalendar e outros locais, problemas de interoperabilidade entre cliente e servidor ocorrem com frequência
• iCalendar e vCard também carregam décadas de dívida técnica
  • Há muitas propriedades raramente usadas ou já obsoletas, e diferenças de implementação entre versões exigem lógica de parsing complexa
• Essa complexidade estrutural prejudica a manutenção e a escalabilidade, tornando essas tecnologias inadequadas para ambientes modernos de colaboração

A chegada do JMAP para as necessidades modernas

• O protocolo JMAP foi originalmente desenvolvido como um protocolo de transporte de e-mail eficiente e simples para substituir IMAP e SMTP
  • Baseado em JSON over HTTPS, ele garante clareza e eficiência de rede ao mesmo tempo
• Agora, com a introdução de JMAP for Calendars, Contacts, Files e Sharing, a mesma filosofia de design se expande para toda a colaboração
  • Fornece uma API unificada e consistente para e-mail, calendário, contatos, arquivos e recursos compartilhados
• JSCalendar e JSContact reorganizam iCalendar e vCard em formatos baseados em JSON
  • Removem propriedades desnecessárias e oferecem um modelo de dados claro e consistente
  • São fáceis de ler por humanos, amigáveis para desenvolvedores e eficientes no parsing, sendo otimizados para aplicações modernas
• A combinação do JMAP com esses novos modelos de dados permite implementar calendário, gerenciamento de contatos e compartilhamento de arquivos de forma mais rápida e confiável

O significado deste lançamento

• Este lançamento vai além de apenas adicionar recursos e representa um ponto de virada na forma de projetar protocolos de groupware
  • Desenvolvedores e organizações podem construir e-mail, contatos, calendário e recursos compartilhados sobre uma única estrutura baseada em JSON
• A simplicidade e previsibilidade do JMAP ajudam clientes e servidores a focar em funcionalidades e experiência do usuário, em vez de no processamento do protocolo
• Como resultado, espera-se redução de problemas de interoperabilidade, aumento da velocidade de desenvolvimento e aceleração da inovação
  • Isso serve como um impulso para promover padronização e maior eficiência em todo o software de colaboração

Suporte de clientes e expansão do ecossistema

• O Stalwart é atualmente o primeiro servidor a oferecer suporte completo a toda a família de protocolos JMAP, mas o suporte do lado dos clientes ainda está em estágio inicial
• Mesmo assim, vários projetos já estão adotando os novos padrões
  • Mailtemi, Parula e OpenCloud estão desenvolvendo clientes para JMAP Calendars, Contacts e File Storage
• O ecossistema está crescendo rapidamente e, à medida que os desenvolvedores experimentarem diretamente a elegância e a robustez do JMAP, espera-se uma adoção acelerada

[t7vonn]

Que legal!!

[GN⁺]

Comentários no Hacker News

• Pelo que vejo, o Stalwart é um excelente servidor JMAP
  Acho que JMAP é um protocolo muito bom para criar clientes de e-mail
  Eu preferiria evitar self-hosting, mas seria interessante usar o Stalwart como componente de servidor para um cliente, sincronizar dados IMAP existentes e acessá-los via API JMAP
  Ouvi dizer que algo como sincronização IMAP-IMAP é possível, então queria saber se alguém já tentou isso com o Stalwart
  Se essa abordagem funcionar, daria para acessar caixas de e-mail IMAP existentes via JMAP, o que pode impulsionar o desenvolvimento de uma nova geração de clientes de e-mail
  • Quero enfatizar que chamar de “excellent” não é exagero
    O Stalwart é realmente um software lindamente estruturado
    É impressionante como foi ganhando confiabilidade e maturidade de forma gradual
    E é surpreendente que isso tenha sido conduzido quase por uma única pessoa desenvolvedora
    Gráfico de contribuidores no GitHub
  • Dá para fazer isso de forma simples com mbsync, uma ferramenta de sincronização IMAP ↔ IMAP
    Basta sincronizar periodicamente o IMAP remoto com o servidor IMAP local do Stalwart, e o Stalwart converte isso internamente para JMAP e entrega dessa forma
    No começo achei que seria preciso passar por uma etapa com maildir, mas parece perfeitamente viável só com IMAP ↔ IMAP
  • Esperei por algo assim por muito tempo
    Tudo o que encontrei até agora era caro demais, então esse avanço é muito bem-vindo
  • Eu também estava pensando nisso pelo mesmo motivo
    Ainda não tenho nada pronto, mas continuo considerando a ideia
• Vejo muita gente dizendo que “não há clientes”, mas é natural que a implementação de servidor venha primeiro
  Como o Stalwart é na prática a primeira implementação de servidor JMAP, agora finalmente existe motivo para criar clientes
  Aliás, o novo serviço de e-mail da Mozilla também deve usar JMAP, então isso pode gerar um grande impulso
  • Acho que o Stalwart pode realmente ser um divisor de águas
    Antes eu já tinha usado groupware como Nextcloud e SoGo, mas fiquei decepcionado
    Agora, porém, o Nextcloud está colaborando com o Stalwart, e Opencloud e Mozilla/Thunderbird também estão integrando JMAP, o que é animador
    Em especial, o projeto de webmail Stormbox do Thunderbird também está em andamento, o que é interessante
    Neste momento há um forte movimento para sair do Big Tech, então o timing é perfeito
  • Vale lembrar que o Stalwart foi o primeiro servidor a implementar contatos e calendário do JMAP
    O Cyrus só suportava JMAP para e-mail
  • O FastMail já usa JMAP em produção e também é coautor da RFC
  • Recentemente implementei sincronização de calendário JMAP no Pimsync
    Agora é possível sincronizar entre CalDAV, JMAP e sistema de arquivos
  • Clientes JMAP existem, sim
    Eu uso o cliente aerc
• JMAP é atraente do ponto de vista de design de API web, mas fico em dúvida se todo protocolo novo precisa ser criado sobre HTTP
  Coisas como compartilhamento de arquivos, groupware, e-mail e calendário talvez pudessem ser projetadas de forma mais eficiente sem o overhead de JSON
  Ainda assim, imagino que exista um bom motivo para esse design baseado em HTTP
  • E-mail originalmente não era um protocolo binário
    Isso porque a maioria dos primeiros protocolos da internet foi criada sobre Telnet baseado em texto
    HTTP/3 é essencialmente um protocolo binário, e JSON é estruturado e comprime bem, então na prática ele é bastante eficiente
    “JSON over HTTP” é uma melhoria sutil, mas real, em relação a “texto customizado sobre telnet”
  • Criar seu próprio formato de serialização geralmente só aumenta os problemas
    Mesmo usando frameworks como capnproto, grpc ou ASN.1, cada um traz sua própria complexidade
    JSON é simples e tem limitações bem claras, então é fácil de lidar
    Já designs dependentes de implementação, como o protocolo do Microsoft Exchange, acabam causando problemas no longo prazo
  • Colocar tudo sobre HTTP nem sempre é a melhor ideia
    Em alguns casos, um protocolo diferente de TCP pode ser melhor
    Pessoalmente não gosto de JSON e acho o formato DER melhor
    Protocolos de “small web” como Gemini e Scorpion também são interessantes
  • O overhead de buscar e-mail por HTTP não é grande
    Na verdade, em termos de compatibilidade com clientes web, HTTP é a única escolha
    Não vejo quase nenhuma vantagem em não usar HTTP
  • HTTP/2 e HTTP/3 já são protocolos binários
    Se usar CBOR no lugar de JSON, o payload também pode ser binário
    HTTP é um protocolo de transferência de estado (state transfer), então é adequado para sincronização
    Com a extensão Braid, ele também pode ser expandido para um protocolo de sincronização de estado (state synchronization)
    Eu trabalho no projeto Braid
• Espero que o Fastmail implemente logo a parte de calendário e contatos do JMAP
  E-mail já é suportado, mas ainda é preciso usar CardDAV/CalDAV em paralelo
  • Atualmente eles usam internamente uma versão antiga do JMAP
    O código caldav_sync escrito há 10 anos ainda está rodando
    Recentemente melhoraram a lógica de geração de objectid para reduzir o tamanho dos IDs e aumentar a capacidade de ordenação
    Agora vão atualizar calendário e contatos para a especificação mais recente do JMAP
    O sistema de arquivos provavelmente ainda vai demorar um pouco mais
  • A especificação JMAP Calendar ainda não foi aprovada oficialmente
    Veja o rascunho do documento
    Contacts foi aprovado há 10 meses como RFC 9610
  • Se grandes clientes como Thunderbird, K-9 Mail e o app Mail do iPhone não derem suporte, vai ser difícil o JMAP se espalhar
    Também não está claro quais problemas ele resolve em relação às soluções existentes
• JMAP é um bom protocolo, mas falta suporte de clientes
  Clientes grandes como Apple Mail, Thunderbird e Outlook precisam suportá-lo
  Até clientes menores como Canary ou Spark poderiam adotá-lo como diferencial, mas curiosamente não fazem isso
  • O Outlook já está virando algo voltado só para MS365
    O novo Outlook armazena todos os dados no Azure e se comunica com o servidor real por meio de proxy
    É muito improvável que venha a suportar JMAP
  • JMAP é bom para clientes leves, tipo webmail, mas não oferece grandes vantagens para apps desktop que armazenam estado localmente
  • Se os grandes provedores de e-mail não derem suporte, o diferencial do JMAP fica fraco
    (não estou defendendo IMAP)
  • Primeiro é preciso haver suporte de servidor
    Se Gmail ou iCloud não suportarem, criar clientes terá pouco sentido
    Até dá para ter suporte duplo, mas o mercado seria pequeno
  • Para o JMAP ter sucesso, ele precisa evoluir para um protocolo integrado de groupware que cubra não só e-mail, mas também calendário, contatos e compartilhamento de arquivos
    Mas isso ainda depende de muitos “ifs”
• Graças ao Stalwart, fazer self-hosting de e-mail ficou bem mais fácil
  Por ser um servidor totalmente integrado, dá a sensação de uma nova era
  O Maddy também é bom, mas sua manutenção é menos ativa
  • Eu também estou migrando de uma combinação Maddy+Postfix+Dovecot+Rspamd para Stalwart, e sinto que a qualidade da documentação é insuficiente
    Não existe uma documentação que mostre de forma clara as opções, os valores padrão e como tudo se relaciona
    Dá para configurar pela Web UI, mas isso entra em conflito com deploy declarativo
    Se o arquivo .toml estiver como somente leitura, ocorre erro
  • Queria saber se existe algum cliente webmail JMAP realmente utilizável
    Fora FastMail e Topicbox, não há muita coisa
    Precisaria ser algo self-hosted por HTTPS, como Roundcube ou Wildduck
  • Não sei se há uma vantagem prática real em relação a Postfix+Dovecot
    Fora o fato de ter sido “reescrito em Rust”, não vejo um diferencial tão claro
• Fico preocupado se vão tentar substituir o Sieve por algo baseado em JSON
  Sem um bom MUA (cliente de e-mail), duvido que JMAP ajude tanto
  O lado do servidor já foi bastante resolvido, mas os clientes estão estagnados
  A maioria nem implementa todos os recursos do IMAP4, e os clientes de Sieve também são bem ruins
  • Não concordo com a ideia de que “o lado do servidor é um problema resolvido”
    O Dovecot ainda não suporta UTF-8 de forma completa
    Projetos como Stalwart são justamente tentativas de superar essas limitações legadas
    Os clientes também tiveram evolução, como no caso do Apple Mail
  • No fim das contas, são necessários servidor e cliente ao mesmo tempo
    Não adianta só um dos lados evoluir
    Agora que existe um bom servidor, o que falta é um bom cliente
• Se você quer uma API JSON no estilo JMAP em ambientes Google Workspace ou Outlook, o Nylas pode ser uma alternativa
  O Nylas é poderoso, mas caro
  Em grande escala, custa US$ 1,50 por conta por mês, o que pode afetar a margem de um SaaS
  Ainda assim, é muito útil para análise de e-mails em tempo real ou para construir interfaces customizadas
• Instalei o Stalwart, e como servidor web e servidor de e-mail são integrados