分散型のチャットサービスというと、専用アプリや新しい操作体系を想像しがちだが、Parleyはかなり違う方向を向いている。見た目も使い方もできるだけ普通のIRCに寄せ、そのうえで各ドメインが自前で運用できる連合型の会話網を作ろうとしている。今回の更新は、その設計が単なる理想論ではなく、実際に動く形でどこまで詰められているのかを示す内容だ。特に、相手のインスタンスが先に「こんにちは」と言ってきた場合でも、その相手の情報をきちんと記録する修正は、分散システムらしい地味だけれど重要な手当てだと思う。
Parleyは、中心サーバーを持たないチャットネットワークを作るプロジェクトだ。各人や各チームが自分のドメイン用の小さなインスタンスを立て、DNSと .well-known の公開情報で互いを見つけ、署名付きのHTTPメッセージでやり取りする。その上で、利用者からは平凡なIRCサーバーに見えるように作られている。irssi、WeeChat、Textualのようなクライアントをそのままつなぎ、追加プラグインなしで使えるのが売りだ。
利用者名もメールアドレスに近い形を取る。たとえば alice@foo.com と bob@bar.com が別々のインスタンスにいても、Bobが /msg alice@foo.com hi と打てば、その場でインスタンス同士が連携して会話が始まる。まだ会ったことのない相手でも、必要な情報を自動で交換してつながる。READMEでは、これを「working proof of concept」と位置づけていて、設計は端から端まで通して実装しているが、まだ十分に堅牢化された状態ではないとも書いている。
機能面もかなりIRCに寄せている。PASS や SASL PLAIN でログインでき、IRCv3の server-time、message-tags、echo-message、multi-prefix、setname などに対応する。TAGMSG で typing indicator のようなクライアント専用タグも中継できるし、+reply のようなメッセージタグは履歴から再送されても保持される。draft/multiline にも対応していて、貼り付けた段落を8通ではなく1通として扱えるのも面白い。履歴はアカウントにひもづき、端末をまたいで追従する。CHATHISTORY でチャンネルやDMをさかのぼれ、draft/read-marker によって既読位置もサーバー側で共有される。
アカウント管理も、設定ファイルに閉じない作りだ。データディレクトリにアカウントがあり、parleyctl、管理画面、HTTP API、あるいは OpenID Connect や reverse proxy の identity header から作成できる。Bot は bot role を持つアカウントとして扱う。ネットワークの発見は _parley._tcp.<domain> の SRV と、https://<host>/.well-known/parley/instance.json にある ed25519 公開鍵と inbox 情報、さらに /.well-known/parley/<user>.json でユーザー存在確認をする仕組みだ。連携は HTTPS 上の署名付きJSONで行い、受信側は自分で見つけた鍵で検証する。さらに、自分が知らない相手に話しかけると自動でピアリングし、既知の相手情報を互いに広げていくので、設定なしでメッシュが育つ。チャンネルは全体共有のものと、そのインスタンス内に閉じるローカルなものの二種類があり、モデレーションも /ban をマスクベースのブロックとして実装している。履歴はSQLiteに保存され、全文検索にも対応し、停止中に抜けた差分は再接続時に回収する。
今回のコミットは、その中でも連合まわりの細部を直している。相手が先に hello を送ってきた場合、これまでは相手のソフトウェア情報がしばらく空欄のままだった。原因は、送り返す側の hello() では p.software を設定していたのに、受信した側で処理する applyHello() ではインスタンス文書を読み直していなかったためだという。相手からの hello でリンク自体は成立しても、次にこちらから hello を返すまで version が埋まらず、しかもその再リンクは relinkEvery に従って10分待ちになる。相手からのイベントや push、hello が続くとその時計は何度もリセットされるので、忙しいリンクでは空欄がいつまでも続きうる。修正では、受信した TypeHello が相手の version を読み、それを applyHello に渡して記録するようにした。peerSoftware と setSoftwareLocked は両経路で共通化され、ログも「相手がアップグレードした」という扱いも一本化された。テストでは、デフォルト間隔のまま2つのインスタンスをつなぎ、再リンクが起きない条件で双方が相手の version を見られることを確認している。make test は -race 付きで通り、新テストも20回連続で成功。bte check parley.bt はエラー0で、demo/demo.sh でも、bar.com が先に hello を送り、foo.com が自分からは hello を返していない状況で、foo.com 側の /api/v1/peers に bar.com の software が18秒ほどで出たとしている。
Parleyでいちばん印象的なのは、分散チャットを新しいアプリ体験として押し出すのではなく、既存のIRC文化の中に滑り込ませようとしている点だと思う。多くの連合型サービスは、自由度の代わりに学習コストを払わせる。だがParleyは逆で、利用者には「いつものIRC」であることを約束し、その背後だけを分散化している。これは地味だが強い。導入の障壁が低いからだ。
しかも、ただIRC風というだけではない。履歴、既読、タグ、DM、チャンネル、Bot、SSO、検索まで、実運用で面倒になりやすい部分をちゃんと押さえている。分散システムは「つながる」だけでは弱く、日常利用で不便だとすぐ使われなくなる。Parleyはそこをかなり理解しているように見える。私はここに、プロトコルを再発明するより「既にある慣れ」を味方にする設計の強さがあると思う。
今回の修正は小さいが、かなり分散らしいバグだ。片方向の接続だけで済むなら気づきにくいし、動いているように見える。ところが、相手が先に hello を投げてきた経路では version が拾えず、こちらからの再 hello を待たないと埋まらない。しかもその再 hello には10分の待ちがある。こういう「情報はあるのに、記録される経路が一本だけ」という問題は、分散システムで本当によく起きる。
面白いのは、修正方針がかなり素直なことだ。受信した hello でも、検証済みのインスタンス文書から version を読む。つまり「どちらが先に挨拶したか」に関係なく、両側が同じ相手情報を持てるようにする。これは当然に見えるが、実装が一段複雑だと意外と抜け落ちる。私はこの手当てに、Parleyが“ちゃんと運用される分散”を目指している気配を感じた。理屈より、観測される状態を整えることを優先している。
Parleyの価値は、IRC互換の表面だけではない。むしろ、既存クライアントでつながることが運用設計を単純にしているところにあると思う。専用クライアントを配らなくていいし、ユーザー教育も軽い。管理者側から見ても、クライアントを前提にしたサポート地獄を避けやすい。これは特に、小さな組織や自前運用を好むコミュニティに効くはずだ。
一方で、既存のIRCの知識をそのまま当てはめると、少し見誤るかもしれない。Parleyは見た目はIRCでも、中身は相当Web時代的だ。アカウントはインスタンスのデータベースにあり、identity header や OIDC で入れる。履歴はサーバー側で永続化され、既読も共有される。つまり、クライアントが軽い代わりに、サーバーが相当な責任を持つ。私はそこが重要だと思う。互換性は入口であって、本質は「クライアントを選ばず、状態をサーバーに寄せる」ことにある。
READMEが自ら「proof of concept」と言っている通り、Parleyはまだ完成品ではない。だが、だからこそ設計の筋が見える。連合型サービスで難しいのは、単なるメッセージ交換より、誰を信用し、どこまで自動でつなぎ、どこからは管理者が止めるかだ。ParleyはDNS、WKID、署名付きHTTP、マスクベースのban、ローカル/グローバルチャンネルなどで、その境界をかなり細かく切ろうとしている。
私はここに、Fediverse的な「つながりやすさ」と、昔ながらのIRCが持っていた「自前で運用できる気楽さ」を足し合わせたい意図を感じる。ただ、広がるほど大事になるのは技術より信頼だろう。相手インスタンスの版数が正しく見えることも、実は信頼の一部だ。今回の修正はその象徴に見える。小さいけれど、連合の体験はこうした細部の積み重ねで決まるのではないかと思う。
参考: parley
