- オープンソースのコラボレーションサーバー Stalwart が、4年間の開発を経て カレンダー、連絡先、ファイル保存・共有向けJMAP を完全実装し、新たな節目を達成
- 今回のリリースにより、Stalwart は JMAPプロトコル群全体を完全サポートする初のサーバー となり、メールを超えてコラボレーション全般へ拡張された統合APIを提供
- JSONベースの単一フレームワーク によって、既存のWebDAV・CalDAV・CardDAVの複雑さと非効率を置き換え、開発者に優しい構造を実現
- 新しい JSCalendar と JSContact フォーマットは、iCalendar と vCard の複雑さを取り除き、明確で一貫したデータモデルを提供
- これはオープン標準ベースのコラボレーション技術の進化を象徴しており、今後の カレンダリング・ファイル共有・メール統合エコシステムのイノベーション加速 を予告
新世代のプロトコル
- ここ数年、IETF はメール、カレンダー、連絡先の同期と共有の方法を再定義している
- これらの標準は、分断された WebDAVベース技術 を置き換える、統合的で洗練されたエコシステムを提供
- 数十年にわたる互換性の問題を解決し、単一のデータモデルでコラボレーション機能を簡素化する
既存技術の限界
- WebDAV、CalDAV、CardDAV などは長年安定して使われてきたが、XMLベースの設計 により過度に冗長で一貫性に欠ける
- データがHTTPヘッダー、XMLペイロード、iCalendarデータなど複数の場所に分散しており、クライアントとサーバー間の 相互運用性の問題 が頻繁に発生
- iCalendar と vCard もまた、数十年分の技術的負債を抱えている
- 利用頻度の低い、あるいは廃止された属性が多く、バージョンごとの実装も一致しないため、複雑なパースロジック が必要
- こうした構造的な複雑さは保守性と拡張性を損ない、現代的なコラボレーション環境には不向きな状態
現代的要件に応えるJMAPの登場
- JMAPプロトコル は、もともと IMAP と SMTP を置き換えるために開発された、効率的でシンプルなメール転送プロトコル
- JSON over HTTPS ベースで、明確さとネットワーク効率を同時に確保
- いまや JMAP for Calendars、Contacts、Files、Sharing の導入により、同じ設計思想がコラボレーション全体へ拡張された
- メール、カレンダー、連絡先、ファイル、共有リソース向けの 統合的で一貫したAPI を提供
- JSCalendar と JSContact は、従来の iCalendar と vCard を JSONベースのフォーマット として再構成
- 不要な属性を削除し、明確で一貫したデータモデルを提供
- 人間にとって読みやすく、開発者に優しく、パース効率も高いため、現代的なアプリケーションに最適化 されている
- JMAP とこれら新しいデータモデルの組み合わせにより、カレンダリング、連絡先管理、ファイル共有を より高速かつ信頼性高く実装 できるようになる
今回のリリースの意味
- 今回のリリースは単なる機能追加にとどまらず、グループウェアプロトコル設計の転換点 を意味する
- 開発者や組織は、メール、連絡先、カレンダー、共有リソースを 単一のJSONベースフレームワーク 上に構築できる
- JMAPのシンプルさと予測可能性 により、クライアントとサーバーはプロトコル処理よりも機能とユーザー体験に集中できる
- その結果、相互運用性の問題の減少、開発速度の向上、イノベーションの加速 が期待される
- これはコラボレーションソフトウェア全般における 標準化と効率向上 を促進する契機となる
クライアント対応とエコシステム拡大
- Stalwart は現在、JMAPプロトコル群全体を完全サポートする初のサーバー であり、クライアント対応はまだ初期段階にある
- しかしすでに複数のプロジェクトが新しい標準を採用しつつある
- Mailtemi、Parula、OpenCloud などが JMAP Calendars、Contacts、File Storage クライアントを開発中
- エコシステムは急速に成長しており、開発者がJMAPの 洗練さと強力さ を直接体験するにつれて、急速な普及 が見込まれる
2件のコメント
いいですね!!
Hacker Newsのコメント
JMAP はメールクライアントを作るのにとても良いプロトコルだと思う
自前でホスティングするのは避けたいが、Stalwart をクライアントのサーバーコンポーネントとして使い、既存の IMAP データを同期して JMAP API でアクセスできるなら面白そうだ
IMAP-IMAP 同期のようなやり方が可能だと聞いたが、Stalwart で試した人がいるのか気になる
こうしたアプローチが可能になれば、既存の IMAP メールボックスに JMAP でアクセスできるようになり、新世代のメールクライアント開発が進むと思う
Stalwart は本当に 美しく構造化されたソフトウェアだ
信頼を積み上げながら段階的に完成度を高めてきた点が印象的だ
しかもほぼ 1人の開発者が主導してきたという事実に驚く
GitHub のコントリビューターグラフ
リモート IMAP を Stalwart のローカル IMAP サーバーに定期的に同期すれば、Stalwart が内部的にそれを JMAP に変換して提供する
最初は maildir の段階を挟む必要があるかと思ったが、IMAP ↔ IMAP だけで十分にできそうだ
これまで見つけたものは高すぎたので、こういう進展はうれしい
まだ成果物はないが、ずっと考え続けている
Stalwart が事実上 JMAP の最初のサーバー実装なので、これでクライアントを作る理由が生まれたとも言える
参考までに Mozilla の新しいメールサービスも JMAP を使う予定なので、大きな 推進力になると思う
以前は Nextcloud や SoGo のようなグループウェアを使ってみたが、がっかりだった
でも今は Nextcloud が Stalwart と協力し、Opencloud と Mozilla/Thunderbird も JMAP を統合中なので期待している
特に Thunderbird のウェブメールプロジェクト Stormbox も進んでいて興味深い
今は Big Tech から離れようという流れが強いので、タイミングも完璧だ
Cyrus は JMAP メールしか対応していなかった
これで CalDAV、JMAP、ファイルシステム間の同期が可能になった
私は aerc というクライアントを使っている
ファイル共有、グループウェア、メール、カレンダーのようなものは、JSON オーバーヘッドなしでもっと効率的に設計できる気もする
それでも HTTP ベースの設計には確かに理由があるのだろう
初期のインターネットプロトコルの大半がテキストベースの Telnet 上で作られたからだ
HTTP/3 は本質的にはバイナリプロトコルで、JSON は構造化されていて圧縮効率も良いので、実際かなり効率的だ
「JSON over HTTP」は「custom text over telnet」より控えめながら確かな改善だ
capnproto、grpc、ASN.1 のようなフレームワークを使っても、それぞれ固有の複雑さがある
JSON は単純で限界が明確なので扱いやすい
一方で Microsoft Exchange プロトコルのような実装依存の設計は、長期的に問題を生む
場合によっては TCP 以外の別のプロトコルのほうがよいこともある
個人的には JSON は好きではなく、DER 形式のほうが良いと思う
Gemini や Scorpion のような「small web」プロトコルも興味深い
むしろ Web クライアント互換性の観点では HTTP が唯一の選択肢だ
HTTP を使わない利点はほとんどないと思う
JSON の代わりに CBOR を使えばペイロードもバイナリ化できる
HTTP は 状態転送(state transfer) プロトコルなので同期に向いている
ここに Braid 拡張 を加えれば 状態同期(state synchronization) プロトコルへ拡張できる
私は Braid プロジェクトで働いている
メールはすでに対応しているが、まだ CardDAV/CalDAV を併用しなければならない
10年前に書いた caldav_sync コードがまだ動いている
最近は objectid 生成ロジックを改善して ID サイズを縮小し、ソート性も高めた
これから最新の JMAP 仕様に合わせてカレンダーと連絡先を更新する予定だ
ファイルシステムはもう少し時間がかかりそうだ
草案ドキュメント を参照
Contacts は RFC 9610 として 10か月前に承認された
既存ソリューションに比べて何の問題を解決するのかも明確ではない
Apple Mail、Thunderbird、Outlook のような主要クライアントが対応する必要がある
Canary や Spark のような小規模クライアントが差別化ポイントとして採用してもよさそうなのに、意外とそうなっていない
新しい Outlook はすべてのデータを Azure に保存し、実際のサーバーとはプロキシ経由で通信する
JMAP をサポートする可能性はほとんどない
（IMAP を擁護しているわけではない）
Gmail や iCloud が対応しなければクライアントを作っても意味が薄い
デュアル対応は可能だろうが、市場は狭い
ただしそれはまだ多くの「if」が残る話だ
完全統合型サーバーなので、新しい時代が開けた感じがする
Maddy も悪くないが、メンテナンスはそれほど活発ではない
オプションやデフォルト値、その相互関係をひと目で見られるドキュメントがない
Web UI で設定できるのはよいが、宣言的デプロイとは衝突する
.toml ファイルが読み取り専用だとエラーになる
FastMail や Topicbox 以外にはこれといったものがない
Roundcube や Wildduck のように HTTPS でセルフホストできるものが必要だ
「Rust で書き直した」以外に明確な差別化が見えない
良い MUA（メールクライアント）がない状況で、JMAP が役に立つのか疑問だ
サーバーはすでに解決済みの問題だが、クライアントは停滞している
IMAP4 の機能ですら大半が実装されておらず、Sieve クライアントもひどい
Dovecot はいまだに UTF-8 すら完全には対応していない
Stalwart のようなプロジェクトは、こうした レガシーの限界を乗り越えようとする試みだ
クライアントも Apple Mail のように進化した例がある
どちらか一方だけ進歩しても意味がない
いまや良いサーバーができたのだから、残るのは良いクライアントだ
Nylas は強力だが価格が高い
大規模ではアカウントあたり月額 $1.50 なので、SaaS のマージンに影響する可能性がある
それでもリアルタイムのメール分析やカスタム UI 構築には非常に有用だ