本文へ
ハクソク

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

Parley: フェデレーテッドで分散型のチャット、プレーンIRCに対応

元記事: 原文(git.mills.io)

概要

  • Parley は、従来のIRCクライアントと互換性のある 分散型チャットネットワーク。
  • 各ユーザーまたはチームが 独自のインスタンス を運用し、DNSと公開鍵で相互発見。
  • HTTPS署名通信 による安全なメッセージ交換と自動ピアリング。
  • アカウント管理や履歴同期、モデレーション機能を搭載。
  • 証明済みPoC として動作するが、本番運用には注意が必要。

Parley:分散型IRCチャットネットワークの特徴

  • 中央集権のないネットワーク 構成。
  • 各インスタンスが 独自ドメイン で運用され、 DNS SRVレコード と well-knownドキュメント で相互発見。
  • HTTPS経由で署名付きJSONメッセージ を交換、信頼性の高い通信を実現。
  • 標準IRCクライアント (irssi, WeeChat, Textual等)でそのまま利用可能、追加プラグイン不要。
  • メールアドレス形式のID (例: [email protected])、他インスタンス間のメッセージが即時利用可能。
  • グローバルチャンネル (#lobby等)と ローカルチャンネル (&notes等)を区別。
  • アカウント管理 はWeb UI、CLI、HTTP API、またはSSO(OpenID Connect等)で対応。
  • 履歴同期 :クライアントをまたいだ既読管理、JOIN時に未読履歴を自動リプレイ。
  • SQLiteによる全文検索付き履歴保存、ダウンタイム復旧時も自動同期。
  • モデレーション :チャンネル所有者がいないため、BANはマスクによる個別/インスタンス単位のブロックリスト方式。
  • 自動ピアリング :新規ドメイン宛のメッセージ送信時に自動でリンク生成、ピア情報のゴシップ交換でメッシュ形成。

Parleyの導入・運用方法

  • Dockerイメージ (prologic/parley)とdocker-compose.example.ymlで簡単導入。
  • インスタンスデータは永続ストレージ(/data)に保存:鍵・ピアキャッシュ・ログ・アカウント管理。
  • アカウント作成 はparleyctl、管理Webページ、またはSSO経由で実施。
  • HTTPSフロント :TLS終端は任意のリバースプロキシで対応、parleyd自体はプレーンHTTP。
  • SRVレコード 必須:他インスタンスからの発見性確保。
  • IRC over TLS :クライアントからはTLS経由で接続、parleydのIRCリスナーはプレーンテキスト。
  • 接続確認ツール (parleyctl check):SRVレコード、well-knownドキュメント、エンドポイント、inbox、IRC TLSポートを検証。

Parleyの構成・設定

  • 設定ファイルなし、全てフラグまたは環境変数で定義。
  • 起動前に必要な情報はフラグ/環境変数で指定(例:-domain, -data, -endpoint等)。
  • ランタイム中に変更可能な設定はDBに保存、Web UIやparleyctlで即時反映。
  • アカウント・ネットワーク管理、制限・履歴保持・認証方式・テーマカラーなど多様な設定項目。
  • ユーザーアイコン やインスタンスロゴもWeb UIから設定可能。

Parleyの通信フローとプロトコル

  • メッセージ送信時 の流れ:
    • 送信側インスタンスが宛先インスタンスのSRVレコードをDNSで検索。
    • well-knownドキュメントから公開鍵とinboxを取得。
    • イベント(JSON)に署名を付け、HTTPSでinboxへPOST。
    • 受信側が署名検証・メッセージ配信、ピア情報の相互交換。
  • Wireプロトコル、APIの詳細は公式ドキュメント(docs/PROTOCOL.md, docs/API.md)参照。

Parleyの主な制限事項・注意点

  • 現状は PoC(概念実証) レベル、本番運用には十分なセキュリティ検証が必要。
  • SRVレコード未設定 の場合、他インスタンスからの発見不可。
  • IRCリスナーはプレーンテキスト のため、TLS終端の設定ミスに注意。
  • 設定・運用ミス による情報漏洩や接続障害のリスク。

この内容はParleyの公式README等を日本語で簡潔にまとめたものであり、導入検討や運用開始時の参考資料として利用可能。

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

Parleyは中心がないチャットネットワークだよ。各人(またはチーム)が自分のドメイン用に小さなインスタンスを運営してるんだ。インスタンス同士はDNSやよく知られたアイデンティティドキュメントを通じて見つけ合って、HTTPSで署名されたメッセージを交換する。そして、LurkerやMango、mIRC、WeeChat、Textualなどの普通のIRCクライアントに、プラグインなしで全体のフェデレーテッドネットワークを提示するんだ。

└

一般のユーザーが自分のインスタンスを立てずに簡単に使えるの?

└

これはTFAのAI生成の要約?

これ、結構好きなんだけど、スパムがすぐに問題になりそうな気がする。

└

それは常に心配だね。スパムをするユーザーやインスタンスをブロックできるよ。

面白いね。オープンリンクネットワークを使えばいいのに。結果的には同じような状態になると思う。スパムはここでも問題になるだろうし、異なるバックエンドを使うと既存のツールを使うのが難しくなるよ。&チャンネルを使うのは楽しいけど、その特定のIRCの歴史に直面したときにどれだけのボットやクライアントがダウンするか見てみたいな。

└

IRCのリンクはめちゃくちゃだね。スパニングツリーの要件があるからね。それに、RFCにあるサーバー間プロトコルはゼロのサーバーによって話されているから、どの非公式プロトコルが一番好きか選ばなきゃいけない。自分のユースケースに合ったプロトコルを自分で考えた方がいいかも。

こういうのに似たことを考えてたけど、プライバシーに関する理由で2種類のチャットルームを用意してたんだ。* 通常のチャット:サーバー上にだけ存在して、ユーザー以外にはチャットの記録が漏れないけど、サーバー間では絶対に漏れない。* チャンバー:サーバーにあるグローバルチャットルームで、誰でもサブスクライブできるMQTTがあるかも。これ、初期の計画段階から出たことはなかったけど、フェデレーテッドチャットルームと通常のチャットルームの分離がIRCのオープンだけどクローズドなチャットの性質に合わせて興味深いと思ったんだ。

└

これに関しては似たような感じだね。&roomはローカルだけど、#roomはフェデレーテッドなんだ。

つまり、ルームはホストが知ってるサーバー間で「グローバル」ってこと? それなら、ずっと巨大なネットスプリットパーティーみたいで、サーバー管理者だけが誰かをバンできるってこと?

└

バンはサーバーごとに行われるみたいだね(私が見た限りでは)。フェデレーテッドルームは、サーバーが落ちても存在し続けるよ。なぜなら、どのサーバーもそれを「所有」してないから。

LLMベースの開発には特有のデメリットがあって、新しいプロジェクトに首まで浸かっても、既存の分野の作業と接点を持たないことがあるんだ。この場合、これはXMPPの半分の実装がうまく指定されてない状態だね。もちろん、LLMがそのことに触れるだろうと思ってたけど、リポジトリには何も書いてない。

Hacker Newsで議論の続きを見る