実は,MXやGnutellaは既にそれを実現しています. しかし,ファイル共有の比重があまりにも大きいので, 完璧にアングラツールとしてしか使われておらず, 普通に友達と連絡を取るのにあれを起動しようなんて気分にはなれないのが困り者. さらに,有名になったサーバープログラムは,攻撃対象としても狙われやすいので. この世界,広まっている物ほど良いとは限りません.
また,ファイル共有にも関連して, いろんなリスト情報をキャッシュするサーバーが無いとあまりにも負荷が高くなるため, bearshareやMXでは, 事実上かなりの部分がハイブリッドP2P(サーバーがあるもの)的な動きをしています.
これらの事実を鑑みて, もっと小規模でも気軽に立ち上げられるIMツールを目指そうというものです.
ICQは,ユーザーの状態やIPアドレス, さらにメッセージ自体もサーバーがやり取りします. さすがにファイル転送はP2Pでやらせます. こういう形態はプログラムの作り方として非常に良いのですが, サーバーが無いとどうにもなりません. すなわち,企業が何らかの理由で無料で提供すると言うことはあっても, 完全に企業から独立したフリーなサービスとしては成立しにくい.IRCは非常にそれに近いですが, 規格が古いためにユーザーの特定や守秘性への配慮がいまいち. さらにユーザー数が極めて多いため, 有名なサーバーでは頻繁に接続や通信トラブルが起きています.
そこで,IRCやICQのようなサービスに, Gnutellaのような完全P2P性をもたせてやろうというものです. GnutellaそのものやMXじゃなぜいけないかというと,序文で書いたとおりです.
(補足：デーモンが立てられるサーバーは無理でも, perlなんかで書いたIP登録用スクリプトをあちこちに立てて, 数分間隔でポーリングすれば通信はできる. ってのは僕も考えましたが, そんなペースでアクセスされるスクリプトは非常に消されやすいし, レスポンスから言っても数人規模でなくなったらどう考えても困る気がするので, いろいろ考えたけど断念. ただし,全ユーザー情報を得るのでなくて, 長時間起動している人のＩＰを記録しておいて, P2Pネットワークへの最初のアクセスポイントの一つとして使うなら有効かもです. )
・ユーザー名とIPをキャッシュ
で,原理的には,ユーザー名とIPアドレスの対応さえ伝達できれば, 後は直接通信でなんでもできるので, いかにして新しい参加者が,目的の人のIPを知るかが,最初の問題です.これは,サーバーありのタイプならもちろんサーバーがすべて覚えてるのですが, bearshareやMXでも,実際はリフレクトサーバーと呼ばれるマシンがキャッシュしています. しかし,そのようなサーバーが無くても, インストールして初回起動する時さえなんとかすれば, ２回目以降の起動では,前回知っていたユーザー名とIPのリストを覚えておけば, それら全員が落ちたりIPが変わったりしていない限り, 再度ネットワークに参加することが可能です. どれか一人にでも連絡がつけば, 「原理的には」他の全てのユーザー情報をその人経由で教えてもらうことは可能です. 今では常時接続で10日や20日ぶっ続けで接続しているひとはざらなので, 10人程度のネットワークでもこの方式で十分行けると思います.
もちろん,利用者が数十万というレベルになってくると, そんな情報を仲介させられる人はたまったものじゃないので, bearshareやMXのように要所にリフレクトサーバーを置く必要に迫られますが, これらの方法は排他的なものではないので, サーバーがあればより軽く,ない場合はそれなりにというプロトコルにするべきです.
・ファイル検索は(当初は)付けない.
ファイル入手のあり方を変えてしまう可能性を持った機能ですが, これがあると絶対にわれず交換にしか使われません. そのためにMX等があるわけですから,われずはわれず屋, IMはIMということで,あえて付けないべきでしょう. これによって,ある程度ユーザーが増えても, 心配するのは名前-IP対応のやり取りに限ればいいので, サーバー無しで使える可能性がだいぶ高まります.もちろん,個人間でのファイル転送はあったほうが便利ですから, 指定した相手の提供ファイルをブラウズして送受信するのは普通にやります.
・XMLを使うので, いちおうJXTAに合わせられる所は合わせる.
このようなツールでやりとりされるのは, 複雑な構造を持ち,拡張の余地を大きく持ったメッセージ群です. それをICQのように独自形式で 「先頭から＊＊バイト目の＊＊ビットがファイル送信のリクエスト」 みたいいやってもいいですが,流行から言ってXMLでもよい. FireWallの中からでも使えるようにするにはどのもちHTTPに乗せないといけないので, XMLにしておくのが良かろう. と.で,そういった規格がsunのエンジニアによって提唱されていて, JXTAと言います. まだまだ日の浅いプロジェクトで,規格も日々変わっていると思いますが, こちらの目的を保ったままで互換性が取れる部分は取ったほうが良いので, 良く調べた方がいいです. 本職がいっぱい参加してるんだし.
・マスカレード,Firewallに最大限配慮する.
このへんは先行のプログラムではあまり考慮されていない. もちろん片方がマスカレード内部であっても, もう片方からコネクションをはり続けてそこで送受信というのは常識ですが (IRCのDCCなんかではこれが常識じゃないので不便きわまりなし), 両方がプライベートアドレスのときに何ができるかは非常に怪しい. 第三者をパケットリフレクタとして使えばもちろんＯＫだけど, そんな使われ方は誰だって嫌がるのでなかなか実装しにくいところ. しかし,ピュアP2Pにするならどのみちユーザーリストの伝播でそのような通信が ばんばん行われるので,メッセージのやり取りくらい許してもらえるかな.FireWall内部の場合はある意味もっと不便で,コネクションは誰が仲介しても絶対張れない. でも,HTTPプロクシーというのはそれ自身リフレクタなので, IMの通信をHTTPに載せられるようにしておけば問題無く通信可能. そういうIMはとても少ないのでこれ重要.
ただし,そうやってメッセージが他人のマシンを通過するなら, ある程度の暗号化は必須です.
その他,考えたことをちょこちょこ書き足していく予定.