- Máy chủ cộng tác mã nguồn mở Stalwart đã đạt một cột mốc mới sau 4 năm phát triển khi hoàn thiện đầy đủ JMAP cho lịch, danh bạ, lưu trữ và chia sẻ tệp
- Với bản phát hành này, Stalwart trở thành máy chủ đầu tiên hỗ trợ đầy đủ toàn bộ họ giao thức JMAP, cung cấp một API hợp nhất mở rộng từ email sang toàn bộ lĩnh vực cộng tác
- Thông qua một framework duy nhất dựa trên JSON, giải pháp này thay thế sự phức tạp và kém hiệu quả của WebDAV, CalDAV và CardDAV, đồng thời hiện thực hóa một cấu trúc thân thiện với nhà phát triển
- Các định dạng JSCalendar và JSContact mới loại bỏ sự phức tạp của iCalendar và vCard, cung cấp mô hình dữ liệu rõ ràng và nhất quán
- Đây là biểu tượng cho sự tiến hóa của công nghệ cộng tác dựa trên tiêu chuẩn mở, đồng thời báo hiệu sự tăng tốc đổi mới của hệ sinh thái tích hợp lịch, chia sẻ tệp và thư trong tương lai
Giao thức của thế hệ mới
- Trong vài năm gần đây, IETF đang tái định nghĩa cách đồng bộ hóa và chia sẻ email, lịch và danh bạ
- Dựa trên thành công của JMAP for Mail hiện có, các giao thức mở rộng mới cho lịch, danh bạ, tệp và chia sẻ đã được giới thiệu
- JMAP for Calendars - giải pháp thay thế hiện đại cho CalDAV và lập lịch CalDAV
- JMAP for Contacts – giải pháp thay thế mạnh mẽ cho CardDAV
- JMAP for File Storage – thay thế kho lưu trữ tệp dựa trên WebDAV
- JMAP Sharing – hậu duệ hiện đại của WebDAV ACL
- JSCalendar - iCalendar tiến hóa theo hướng gọn gàng, dựa trên JSON
- JSContact – hậu duệ hiện đại hóa, dựa trên JSON của vCard
- Các tiêu chuẩn này mang lại một hệ sinh thái hợp nhất và thanh lịch, thay thế các công nghệ phân mảnh dựa trên WebDAV
- Giải quyết các vấn đề tương thích tồn tại hàng chục năm và đơn giản hóa các chức năng cộng tác bằng một mô hình dữ liệu thống nhất
Giới hạn của công nghệ hiện có
- WebDAV, CalDAV và CardDAV đã được sử dụng ổn định trong thời gian dài, nhưng do thiết kế dựa trên XML nên quá dài dòng và thiếu nhất quán
- Dữ liệu bị phân tán ở nhiều nơi như header HTTP, payload XML và dữ liệu iCalendar, nên vấn đề tương tác liên vận hành giữa client và server thường xuyên xảy ra
- iCalendar và vCard cũng đang mang theo khoản nợ kỹ thuật tích lũy trong nhiều thập kỷ
- Có nhiều thuộc tính ít được dùng hoặc đã bị loại bỏ, và việc triển khai không đồng nhất giữa các phiên bản đòi hỏi logic phân tích cú pháp phức tạp
- Sự phức tạp mang tính cấu trúc này cản trở khả năng bảo trì và mở rộng, khiến chúng không còn phù hợp với môi trường cộng tác hiện đại
Sự xuất hiện của JMAP phù hợp với nhu cầu hiện đại
- Giao thức JMAP ban đầu được phát triển như một giao thức truyền thư hiệu quả và đơn giản nhằm thay thế IMAP và SMTP
- Dựa trên JSON over HTTPS, nó đồng thời đảm bảo tính rõ ràng và hiệu quả mạng
- Giờ đây, với sự xuất hiện của JMAP for Calendars, Contacts, Files và Sharing, cùng triết lý thiết kế đó đang được mở rộng sang toàn bộ lĩnh vực cộng tác
- Cung cấp API hợp nhất và nhất quán cho thư, lịch, danh bạ, tệp và tài nguyên chia sẻ
- JSCalendar và JSContact tái cấu trúc iCalendar và vCard hiện có thành định dạng dựa trên JSON
- Loại bỏ các thuộc tính không cần thiết và cung cấp mô hình dữ liệu rõ ràng, nhất quán
- Dễ đọc với con người, thân thiện với nhà phát triển, có hiệu quả phân tích cú pháp cao và được tối ưu cho ứng dụng hiện đại
- Sự kết hợp giữa JMAP và các mô hình dữ liệu mới này giúp triển khai lịch, quản lý danh bạ và chia sẻ tệp nhanh hơn và đáng tin cậy hơn
Ý nghĩa của bản phát hành lần này
- Bản phát hành này không chỉ là bổ sung tính năng đơn thuần mà còn đánh dấu một bước ngoặt trong cách thiết kế giao thức groupware
- Nhà phát triển và tổ chức giờ có thể xây dựng thư, danh bạ, lịch và tài nguyên chia sẻ trên một framework duy nhất dựa trên JSON
- Sự đơn giản và tính dễ dự đoán của JMAP giúp client và server tập trung vào tính năng và trải nghiệm người dùng thay vì xử lý giao thức
- Kết quả là có thể kỳ vọng giảm vấn đề tương tác liên vận hành, tăng tốc phát triển và thúc đẩy đổi mới
- Đây sẽ là chất xúc tác thúc đẩy chuẩn hóa và nâng cao hiệu quả cho toàn bộ phần mềm cộng tác
Hỗ trợ phía client và mở rộng hệ sinh thái
- Stalwart hiện là máy chủ đầu tiên hỗ trợ đầy đủ toàn bộ họ giao thức JMAP, dù hỗ trợ phía client vẫn còn ở giai đoạn đầu
- Tuy nhiên, đã có nhiều dự án bắt đầu áp dụng các tiêu chuẩn mới
- Mailtemi, Parula và OpenCloud đang phát triển client cho JMAP Calendars, Contacts và File Storage
- Hệ sinh thái đang tăng trưởng nhanh chóng, và khi các nhà phát triển trực tiếp trải nghiệm sự thanh lịch và sức mạnh của JMAP, có thể kỳ vọng sự lan rộng nhanh chóng
2 bình luận
Hay đấy!!
Ý kiến trên Hacker News
Tôi nghĩ JMAP là một giao thức rất tốt để xây dựng ứng dụng khách email
Tôi không muốn tự host, nhưng sẽ rất thú vị nếu có thể dùng Stalwart làm thành phần máy chủ cho ứng dụng khách, đồng bộ dữ liệu IMAP hiện có và truy cập qua API JMAP
Tôi nghe nói có thể làm theo kiểu đồng bộ IMAP-IMAP, nên cũng tò mò không biết đã ai thử với Stalwart chưa
Nếu cách tiếp cận này khả thi, nó sẽ cho phép truy cập các hộp thư IMAP hiện có qua JMAP, từ đó thúc đẩy việc phát triển thế hệ ứng dụng khách email mới
Stalwart thực sự là một phần mềm có cấu trúc rất đẹp
Tôi rất ấn tượng với việc nó đã dần hoàn thiện trong khi từng bước xây dựng được niềm tin
Hơn nữa, thật đáng kinh ngạc khi gần như được dẫn dắt bởi một nhà phát triển duy nhất
Biểu đồ người đóng góp trên GitHub
Chỉ cần đồng bộ IMAP từ xa định kỳ vào máy chủ IMAP cục bộ của Stalwart, rồi Stalwart sẽ nội bộ chuyển nó sang JMAP để cung cấp
Ban đầu tôi nghĩ phải đi qua bước maildir, nhưng có vẻ chỉ IMAP ↔ IMAP là đã đủ
Những gì tôi tìm được cho tới giờ đều quá đắt, nên thật mừng khi thấy bước tiến này
Chưa có kết quả gì, nhưng vẫn đang tiếp tục nghĩ về nó
Stalwart trên thực tế là triển khai máy chủ JMAP đầu tiên, nên giờ mới có lý do để xây dựng client
Ngoài ra, dịch vụ mail mới của Mozilla cũng dự định dùng JMAP, nên tôi nghĩ đây sẽ là một động lực lớn
Trước đây tôi đã thử các giải pháp groupware như Nextcloud hay SoGo nhưng đều thấy thất vọng
Nhưng giờ Nextcloud đang hợp tác với Stalwart, còn Opencloud và Mozilla/Thunderbird cũng đang tích hợp JMAP, nên rất đáng kỳ vọng
Đặc biệt, dự án webmail Stormbox của Thunderbird cũng đang được triển khai nên càng thú vị: Thunderbird's webmail project Stormbox
Hiện tại xu hướng rời xa Big Tech đang rất mạnh, nên thời điểm này là hoàn hảo
Cyrus trước đây chỉ hỗ trợ JMAP cho mail
Giờ có thể đồng bộ giữa CalDAV, JMAP và hệ thống tệp
Tôi đang dùng client tên là aerc
Những thứ như chia sẻ tệp, groupware, mail, lịch có lẽ vẫn có thể được thiết kế hiệu quả hơn mà không cần overhead của JSON
Dù vậy, chắc hẳn thiết kế dựa trên HTTP cũng có lý do rõ ràng
Vì đa số giao thức Internet ban đầu được xây dựng trên Telnet dạng văn bản
HTTP/3 về bản chất là giao thức nhị phân, còn JSON có cấu trúc và nén khá hiệu quả nên trên thực tế cũng khá tối ưu
“JSON over HTTP” là một cải tiến tinh tế nhưng chắc chắn so với “custom text over telnet”
Dù dùng các framework như capnproto, grpc hay ASN.1 thì mỗi thứ vẫn có độ phức tạp riêng
JSON đơn giản và có giới hạn rõ ràng nên dễ xử lý
Ngược lại, các thiết kế phụ thuộc vào cách triển khai như giao thức Microsoft Exchange sẽ gây ra vấn đề về lâu dài
Trong một số trường hợp, giao thức khác ngoài TCP có thể phù hợp hơn
Cá nhân tôi không thích JSON và nghĩ định dạng DER tốt hơn
Các giao thức “small web” như Gemini, Scorpion cũng khá thú vị
Xét về khả năng tương thích với web client thì HTTP gần như là lựa chọn duy nhất
Tôi không thấy có nhiều lợi ích khi không dùng HTTP
Nếu dùng CBOR thay cho JSON thì payload cũng có thể trở thành nhị phân
HTTP là giao thức truyền tải trạng thái (state transfer) nên phù hợp cho đồng bộ
Nếu thêm mở rộng Braid thì có thể mở rộng thành giao thức đồng bộ trạng thái (state synchronization)
Tôi đang làm việc trong dự án Braid
Mail thì đã hỗ trợ rồi, nhưng hiện vẫn phải dùng song song CardDAV/CalDAV
Đoạn mã
caldav_syncviết từ 10 năm trước vẫn đang chạyGần đây họ đã cải thiện logic tạo objectid để giảm kích thước ID và tăng khả năng sắp xếp
Giờ họ dự định cập nhật lịch và danh bạ lên đặc tả JMAP mới nhất
Hệ thống tệp có lẽ sẽ mất thêm thời gian
Xem bản thảo tài liệu
Còn Contacts đã được phê chuẩn 10 tháng trước dưới dạng RFC 9610
Cũng chưa rõ nó giải quyết vấn đề gì rõ rệt hơn so với các giải pháp hiện có
Các client lớn như Apple Mail, Thunderbird và Outlook cần phải hỗ trợ
Sẽ hay nếu các client nhỏ hơn như Canary hay Spark áp dụng nó như một điểm khác biệt, nhưng ngạc nhiên là họ chưa làm
Outlook mới lưu toàn bộ dữ liệu trên Azure và giao tiếp với máy chủ thực qua proxy
Gần như không có khả năng nó sẽ hỗ trợ JMAP
(Không phải là tôi đang bênh IMAP)
Nếu Gmail hay iCloud không hỗ trợ thì dù có làm client cũng ít ý nghĩa
Có thể hỗ trợ song song, nhưng thị trường sẽ hẹp
Nhưng đó vẫn là câu chuyện còn rất nhiều điều kiện “nếu”
Đây là một máy chủ tích hợp hoàn chỉnh nên có cảm giác như mở ra một kỷ nguyên mới
Maddy cũng ổn nhưng việc bảo trì kém sôi động hơn
Không có tài liệu nào giúp nhìn tổng quan các tùy chọn, giá trị mặc định và mối quan hệ giữa chúng
Có thể cấu hình bằng Web UI nhưng điều đó xung đột với triển khai khai báo
Nếu tệp
.tomlở chế độ chỉ đọc thì sẽ phát sinh lỗiNgoài FastMail hay Topicbox thì không có nhiều lựa chọn phù hợp
Cần một thứ có thể tự host qua HTTPS như Roundcube hay Wildduck
Ngoài việc “được viết lại bằng Rust” thì chưa thấy điểm khác biệt rõ ràng
Trong bối cảnh không có MUA tốt, tôi nghi ngờ JMAP có giúp ích được nhiều không
Phía máy chủ vốn đã là vấn đề được giải quyết rồi, còn client thì đang đình trệ
Ngay cả các tính năng của IMAP4 phần lớn cũng chưa được triển khai đầy đủ, và client cho Sieve cũng rất tệ
Dovecot thậm chí vẫn chưa hỗ trợ UTF-8 hoàn chỉnh
Các dự án như Stalwart là nỗ lực nhằm vượt qua những giới hạn di sản như vậy
Phía client cũng có những ví dụ đã phát triển như Apple Mail
Chỉ một bên phát triển thôi thì không có nhiều ý nghĩa
Giờ đã có máy chủ tốt, nên phần còn lại là client tốt
Nylas rất mạnh nhưng giá khá cao
Ở quy mô lớn, mức $1.50 mỗi tài khoản mỗi tháng có thể ảnh hưởng tới biên lợi nhuận SaaS
Dù vậy, nó vẫn rất hữu ích cho phân tích email thời gian thực hoặc xây dựng UI tùy biến