feat(app): merge local and remote message sources

[ethfumi]

背景

agmsg の DB はインストールごとに独立していて、アプリは自分のマシンのものを見ます。エージェントを1台に集約している構成では、これで過不足ありません。

私は Mac と Windows の両方で開発していて、エージェントもマシンごとに分けています。エージェントは自分が動いているマシンのファイルを触るため、担当する作業がマシンに紐づくと、そのマシンで動かすことになるからです。

この構成に至る前に、DB を1台へ集約し、他方のマシンからは SSH で読みに行く方式を試しました。これは失敗でした。受信 hook はエージェントのターンの区切りごとに走るため、毎回 SSH の往復が入ります。通常は軽くても、相手のマシンが sleep していたり LAN が不安定だったりすると待ちが発生し、エージェントが固まって見えます。ターンの区切りという最も待たされたくない場所に、ネットワークが入っていました。

DB を rsync で同期する案も検討しましたが、SQLite の WAL・既読状態・同時書き込みの衝突を避けるため採用していません。

結果として、各マシンが自分の DB を持ち、メッセージは宛先のいるマシンの DB に書く形に落ち着きました。送受信の経路は完全にローカルで、エージェントのホットパスにネットワークはありません。

残ったのは閲覧だけです。会話は複数の DB に分かれて記録され、1枚の窓に両方は映りません。デスクトップアプリはターミナルと違い、ユーザーが1台の前に座って1つのウィンドウを見る道具なので、ここが効いてきます。ターミナルであれば、Mac の会話は Mac の shell で読めば済みます。

「no daemon, no network」との関係

この変更が README の原則に触れる可能性があることは認識しています。判断はお任せしたいのですが、私の理解では次のようになっています。

• core は変わりません。 bash + sqlite3 のまま、daemon も socket も port も増えません。CLI のユーザーには何も起きません。
• エージェントのホットパスには入りません。 SSH が走るのはアプリの表示 polling であって、受信 hook でもターンの区切りでもありません。
• opt-in です。 app-sources.json を書かなければ挙動は現在とまったく同じで、単一 DB のままです。
• 依存は増えません。 ユーザー自身の SSH クライアントを使い、認証は既存の設定に委ねます。
• remote は読み取り専用です。 書き込めるのはローカル DB だけで、mount・コピー・同期はしません。

ネットワークに触れるのはデスクトップアプリの表示経路だけ、という整理です。ただ、これで原則の範囲内と言えるのかは、私よりも判断できる立場ではないと思っています。

変更内容

Team Room が、暗黙のローカルインストールと、SSH 経由で読み取り専用として参照するインストールを、ひとつの表示に統合できるようになります。source は ~/.agmsg/config/app-sources.json で宣言し、公開インターフェースである api.sh を、システムの SSH クライアント経由で呼びます。

履歴のページングと live カーソルは source ごとに独立して持ちます。メッセージは source で修飾した id で重複排除し、timestamp の安定ソートでマージします。新しい remote は #388 で追加した取りこぼしのない --after-id で polling し、それ以前の core を使っている remote は初回アクセス時に検出して、最新100件を取り直す方式へ fallback します。

対象範囲

remote source は読み取り専用です。spawn・rename・leave・送信はローカル限定のままで、remote のメンバーは名簿とフィルタには現れますが、起動もメッセージ送信もできません。

既知の挙動

複数の source が同じ名前のメンバーを持つ場合、名簿には source ごとに1行ずつ並びます。フィルタは名前単位のため、両方の行のチェックは連動します。名寄せは行っていません。

これは主に、remote のインストールへ直接 join していたメンバーで起きます。その運用こそ本変更が不要にするものなので、必要性が出た時点で対応できればと思っていますが、ご意見あれば伺いたいです。

依存

#388 に依存します。そちらがマージされてからで構いません。

検証

• Rust・フロントエンドのテストと、設定のドキュメントを含みます。
• 実機の2マシン構成（Windows ローカル + SSH 経由の Mac）で確認しました: 履歴の統合表示、Mac 側で書かれたメッセージのライブ受信、読み取り専用の制約、status ドットがローカルの pane にのみ紐づくこと。

おわりに

問題なさそうであれば、マージしていただけると嬉しいです。方針に合わないようであれば、遠慮なく閉じてください。fork で使い続けるので困りません。

需要が私だけのものなのか、他の方にもあるのかも分かっていません。そのあたりも含めてご判断いただければと思います。