ハクソク

世界を動かす技術を、日本語で。

カレンダー、連絡先、ファイルのためのJMAPがStalwartに登場

215日前原文(stalw.art)

概要

  • Stalwart が4年の開発を経て、 JMAPファミリー全対応サーバー として進化
  • JMAP によるカレンダー、連絡先、ファイル共有などの統合サポート
  • WebDAV系技術の課題 を克服し、シンプルかつ効率的なAPIを実現
  • 新世代クライアント の登場やエコシステム拡大が期待
  • 今後は 1.0.0安定版リリース とさらなる改善に注力

Stalwartが切り拓くJMAP時代の幕開け

  • 4年間の開発を経て、 Stalwart がJMAPによるカレンダー、連絡先、アドレス帳、ファイルストレージ、共有機能を完全実装
  • JMAP全ファミリー対応サーバー として初の存在
  • オープンかつ効率的でエレガントな グループウェア基盤 の実現

新世代プロトコルの台頭

  • IETFが近年推進する JMAPファミリー の標準化
    • JMAP for Calendars ：CalDAV/CalDAV Schedulingの近代的代替
    • JMAP for Contacts ：CardDAVの進化形
    • JMAP for File Storage ：WebDAVベースファイルストレージの刷新
    • JMAP Sharing ：WebDAV ACLのモダン後継
    • JSCalendar ：iCalendarのJSONベース進化
    • JSContact ：vCardのJSONネイティブ後継
  • これら標準が 統一的・洗練されたエコシステム を形成

旧来技術(WebDAV等)の限界

  • WebDAV/CalDAV/CardDAV は堅牢だが、XMLベースで冗長・実装困難
  • 情報がHTTPヘッダー・XMLペイロード・iCalendarデータに分散
  • クライアント/サーバー間の 互換性・相互運用性問題 が頻発
  • iCalendar/vCard も肥大化・技術的負債の蓄積
  • 複雑なパースロジックが必要で、エラー多発

JMAP：現代の要件に応える新解

  • JMAP はIMAP/SMTPの近代的代替として誕生
  • シンプル・明快・ネットワーク効率重視の JSON over HTTPS設計
  • メールだけでなく、カレンダー・連絡先・ファイル・共有にも適用範囲を拡大
  • 統一的・実装容易なAPI で個人/グループデータを一元管理
  • JSCalendar/JSContact はiCalendar/vCardのJSON再設計
    • 冗長性排除、表現統一、明快なデータモデル
    • 人間にも開発者にも扱いやすく、パース効率も高い
  • 実装の容易化・高速化・信頼性向上 を実現

JMAP時代の意義

  • 新機能以上に、 グループウェアプロトコル設計の転換点
  • メール・連絡先・カレンダー・共有リソースを 単一JSON基盤 で実装可能
  • 実装容易化・相互運用性向上・イノベーション加速 を期待
  • JMAPのシンプルさが クライアント/サーバー両者のUX向上 に貢献

クライアント対応とエコシステム

  • Stalwart はJMAP完全対応サーバーの先駆け
  • クライアント対応は発展途上だが、 Mailtemi、Parula、OpenCloud 等がJMAP対応を積極開発中
  • エコシステム拡大 とともに、JMAPの利点が広く体験される見込み

感謝と展望

  • NLNet （NGI Zero助成）による開発支援への謝意
  • オープン標準・プライバシー重視技術への貢献

1.0.0リリースに向けて

  • 4年の開発で Stalwart が機能面で完成
  • 今後は DBスキーマ最終化・性能向上・GitHub改善要望対応 に注力
  • 数か月以内の 安定版1.0.0リリース を目指す
  • 最も包括的・エレガント・先進的なJMAPコラボレーション基盤 へ進化
  • これは 始まりに過ぎない

Hackerたちの意見

JMAPは、ちゃんとしたウェブAPIデザインを求める人にはピッタリだけど、新しいプロトコルのデザインスペースは本当にHTTPの上に制約されるべきなのかな？最近、新しいバイナリプロトコルってあるのかな？ファイル共有やグループウェア、メール、カレンダーとか、もっと効率的にできるはずだし、メッセージのやり取りにJSONのオーバーヘッドは必要ないと思うんだよね。とはいえ、これらにはしっかりした考えが詰まってるから、知らない良い理由がたくさんあるかも。まあ、興味深い分野だと思うよ。

└

バイナリプロトコル メールは決してバイナリプロトコルじゃなかった。特にそうで、だからMIMEタイプやMIMEエンコーディングが複雑になるんだよね。ほとんどがプレーンテキスト用に作られたTelnetの上に構築された「古いインターネット」のプロトコル（メール、FTP、さらにはHTTP自体）ってほとんどそうだった。HTTPは新しいTelnetとして、バイナリデータやリクエスト/レスポンスベースのデータフロー、その他の考慮事項に関していくつかの改善がある。HTTP/3はそもそもバイナリプロトコルで、「Telnet互換性」がないのが、ウェブの大部分をそれに切り替えることへの懸念の一つだ。vCard/vCal/iCard/iCalも深く「プレーンテキストフォーマット」だった。JSONは、これらの前のものよりも構造化されていて、効率的だから改善だよ。JSONは効率的に見えないかもしれないけど、圧縮がめちゃくちゃ良くて、gzipやBrotliストリームではかなり効率的だと思う。「HTTP上のJSON」は「Telnet上のカスタムテキストフォーマット」よりも微妙に改善されてる気がする、最初は「バイナリプロトコルの効率」には見えないけどね。特にHTTP/3がHTTPをより効率的で「バイナリ」に、さらには「より基本的」に押し上げてるし、TCP/UDP層での役割も増えてる。（Telnetは絶対にTCPを置き換えようとはしない。）HTTPは新しいプロトコルやアプリを構築するためにインターネットが使える最悪のブートストラップ層ではない。確かに、HTTPスタックの外での多様性や実験も見てみたいけど、今のところHTTPはあまりにも便利だから、独自のプロトコルを作るよりもその上にたくさんのものを構築する方が良いと思う。

└

HTTP/2を使ってCBORに透明にアップグレードできるのかな？

└

新しいプロトコルの設計スペースは本当にHTTPの上に制約されるべきなのかな？ そんなことはないよ。場合によっては役立つけど、そうでない時もある。時には役立つけど、もっと良い方法があるかもしれない。特定のケースに応じて、シンプルなプロトコルにするか、全く新しいプロトコルを作る（TCPを使うかどうかは場合によるし、TCPを使った方が良い時もあれば、そうでない時もある）べきだと思う。 > ファイル共有やグループウェア、メール、カレンダーなど—これらはもっと効率的にできるし、メッセージ交換フォーマットとしてJSONのオーバーヘッドは必要ないと思う。正直、JSONは嫌いだな。問題が多いと思うし、DERの方が良いフォーマットだと思う。（HTTPの複雑さを避ける「スモールウェブ」プロトコル、例えばGeminiやScorpion、Spartan、Titanもあるし、JSON-over-HTTPの代わりにDER-over-Scorpionを使うことも考えたことがある。SSHを使うことも可能だけど、SSHにはバーチャルホスティングがないし。）

└

HTTPでメールを取得するのにどれくらいのオーバーヘッドがかかると思う？ テキストドキュメントをHTTPで取得するのは、まさにそのための使い方だと思う。ウェブクライアントで動くものを持つ唯一の方法だし。HTTPを使わないことの本当の利点が何か思いつかないんだけど、もっと面白いってことくらいかな。

Stalwartを使って自分のメールサーバーをホストするのがめっちゃ楽！こういう完全統合型のメールサーバーが出てきてから、私みたいな自ホスティング派にとって新しい時代が来た感じ。もう一つ良いのはあるけど、あまり活発にメンテナンスされてないMaddyだね。

└

JMAPに使える decent なウェブメールクライアントってあるの？Stalwartが最初に出てきてから何度も聞いてるけど、はっきりした答えがもらえない。結局、FastMailかTopicboxだけ。自分でホストできる、https対応のroudcubeやwildduckみたいなのが欲しいんだよね！

└

今、Stalwartをセットアップ中で、現在のMaddy+Postfix+Dovecot+Rspamdから移行してるところ。あんまり良い経験じゃないな。ドキュメントがあんまり良くない - 全体的なアイデアを得るにはギリギリ足りるかもしれないけど、オプションが何か、可能な値は何か、デフォルトは何か、それらがどう関係してるかの明確な概要がないんだ。Maddyのドキュメントはちょっと雑に見えるけど、ずっと読みやすかった。正直、Stalwartは非最小の静的設定ファイルを書くのを不必要に難しくしてると思う。すべてを正しく接続するのがね。公平に言うと、そんなページがあるかもしれないけど、探しても見つからなかった。Web UIではフォームをクリックして設定できるけど、このアプローチは宣言的なデプロイメントの実践と矛盾してる。私の場合、.tomlファイルが読み取り専用だから、UIで「ローカル設定の書き込みに失敗しました」というログと共に、何の変哲もない500エラーが出てる。

└

でも「新しくてRustで書かれている」以外に、Postfix + Dovecotより本当に得られるメリットってあるの？PostfixとDovecotは何十年も前からあって、ユニックスの哲学に従って一つのことをしっかりやってるし。

Google WorkspaceやOutlookを使ってるクライアントや内部チームとやり取りする必要があって、JMAPスタイル（JMAPじゃないけど）のモダンなJSON APIを求めてる人には、Nylasがいいかもしれないよ。最近、Nylasの価格が少し良くなったけど、まだ高いかな。スケールで月$1.50/接続アカウントって、SaaSの提供の一部ならユーザーごとのマージンに影響しそう。でも、内部の営業チームのメールをキャッチしたり分析したり、カスタムのリアルタイムUIを構築するようなユースケースがあれば、かなり強力だと思う。

JMAPのためにもっと良いクライアントサポートが必要だよ。Apple Mail、Thunderbird、Outlook（ありえないけど）、とかね。CanaryやSparkみたいな小さいのが製品の差別化要素として実装してないのが意外だな。

└

真面目な質問だけど、主要なメールプロバイダーがサポートしないなら、何が差別化要因なの？（これはIMAPを擁護する意図ではないよ。）

└

まずはサーバーのサポートをもっと良くする必要があるね。友達が新しいメールクライアントを作ろうってずっと言ってるんだ。「JMAPだけを使うならやるよ。」って。「それってGmailやApple/iCloudのアカウントも含まれるの？」って聞いたら、「いや、含まれない。」って。Gmailの独自APIとJMAPの両方をサポートするのは理解できるけど、2位から5位の競合がサポートしないなら…意味あるの？（ちょっと悲観的になってごめん。）

└

クライアントやサーバーの導入を促すような魅力的な機能やユースケースはあまりないよね。正直言って、エンドユーザーがメールアクセスのためにJMAPを使いたい理由が分からない。もし、カレンダーや連絡先、ファイル共有などをカバーする一貫した「グループウェア」プロトコルとして、これらの追加RFC提案がうまく展開されて、注目されるサーバー実装が出てきて、クライアントサポートが進むなら面白いけどね。でも、それにはたくさんの「もし」がある。

IMAPの古臭いデザインを考えると、JMAPが選ばれる理由はわかるけど、WebDAVを置き換えるメリットはクライアントには見えないな。他のも微妙だし。『JSON対XML』以上のセールスピッチが必要だと思う（シリアル化は難しくないし、XMLはどこでもサポートされてる）。連絡先やカレンダーは、クライアントがすでに実装してるなら自然にJMAPに従うと思うけど、それは「すでにJMAPメールクライアントを書いた」場合だけだよね。ほとんどの他のケースでは、広くサポートされているプロトコルの方がいいんじゃないかな？

└

そうだね、だってもうみんなWebDAVをサポートしてるし。iOSやAndroidともうまく連携するから、個人的には大きな利点だと思う。でも、stalwartもWebDAVをサポートしてるんじゃないの？

Fastmailがカレンダーと連絡先のJMAP仕様を早く実装してくれることを本当に願ってる。メール部分はしばらく前から実装されてるけど、連絡先やカレンダーのアクセスにはまだCardDAV/CalDAVが必要なんだよね。

└

JMAPカレンダーの仕様はまだ承認されてないと思うよ。https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ そして、連絡先の方はたった10ヶ月前の話だし。https://www.rfc-editor.org/rfc/rfc9610.html

└

ThunderbirdやK-9 Mail、iPhoneのメールクライアントなどの一般的なクライアントがJMAPをサポートしない限り、JMAPのようなプロトコルに何の意味があるの？ 何か特別な努力がないと、絶対に普及しないよ。それに、既存のソリューションで解決されていない問題が何なのかっていう疑問もある。

彼らは堅牢で広く採用され、実績もある。しかし、XMLベースの設計は冗長で、一貫性がなく、正しく実装するのが難しいことで悪名高い。情報はHTTPヘッダー、XMLペイロード、さらには埋め込まれたiCalendarデータに散らばっていて、クライアントとサーバー間で無限の互換性や相互運用性の問題を引き起こしている。これらの問題が広く存在するかどうか、他の人に確認してもらえる？これらのプロトコルは開発が面倒だと思うけど、「堅牢で広く採用され、実績もある」なら、たぶん解決済みの問題なんじゃないかな。どこでも使われる一つの標準がある方が、二つの標準の間で選ぶよりいいよね。

└

その質問は正しいね。常に関連してるし。

2010年頃にAppleでiCalendar、CalDAV、CardDAVのパーサーを作ってたけど、今のMacやiPhone、Apple Watchがもっとモダンなものを使ってるとは思えないな。もう10年以上もそこにはいなかったし。Apple（とGoogle）がこの仕様に対してどう反応するのか、すごく気になる。

└

彼らの提案の中で、これが一番興味深い部分だな。フルカレンダーサーバーを実装するために何が必要か調べたことがあるんだけど、RFCを全部読んだ後、結局そのアイデアからは徐々に離れていったし、もう考えたくもなくなった。

カレンダープロトコルがVTODOの部分を置き換えて、Todoアプリケーションをその上に構築できるようになると思う？ Nextcloudのタスクアプリ用にicsファイルをいじってみたけど、あまり楽しい体験じゃなかったから、そのプロジェクトはちょっと放置しちゃった。

次はどうなるの？Sieveを面倒なものに置き換えて、JSONベースにするの？古い技術（IMAP、Sieve）を使ったMUAのデスクトップ実装って、いいのがないよね。JMAPが役立つとは思えないな。新しい良い（良いと仮定して、確信はないけど）プロトコルを持つ良いサーバーがあっても、良いクライアントがなかったら意味ないじゃん。IMAP4は現代のクライアントにあまり使われてないし、サーバー上にクライアント設定を効率的に保存できるのに、クライアント側で実装してるところがないよ。フォルダーごとのSieveスクリプトを設定できるのに、クライアント側で実装してるところもないし。グローバルスクリプト用の良いSieveクライアント（フォルダー名のオートコンプリートとか）すら実装されてないし、フォルダーごとのものは言うまでもない。そもそも、良いSieveエディタすらないよ！(Electronで作られたSieveクライアントのことは知ってるけど、あれは良くないし、不完全でバグも多い)。サーバーは解決済みの問題（sendmail、exim、postfix、dovecot、cyrus）だけど、クライアントはそうじゃない。GMailが発表された時点で停滞しちゃったんだよね。