MXの次はなんなんだ？

夜中に実装して昼間仕事だからここんとこぜんぜん寝てねー（ｗ

とりあえず隣のクライアントへのファイル検索機能まではできた。
次、一番面倒な分散通信部の実装やね。

まだ実装が完成してないんで最終的にどうなるかはわかんないけど、
今の予想設計だとファイルを落とし始まった時点での接続は
（おっと、検索時はノードをのんびりと渡り歩くんで別よ）

検索者　<-----> 中継ノード <------> ファイル提供者

か、

検索者　<---> 中継ノード１ <------> 中継ノード２ <------>ファイル提供者

のどちらかになると思われ。もちろんこう見えるだけで実は

検索者　<---------> 串のキャッシュを送ってるように見えるファイル提供者

こうなってる可能性も発生する
（これは実際にはそれほど発生しないはず。上流に来易い
高速回線経由のクライアント間ほどこれが発生するかなー）

どっちにしろ、だれが検索者でだれが最終的なファイル提供者か
ネットワークの一部分を見ているだけではわからない。

暗号化も入るしMXよりはかなり安全なはず。
（もちろん249氏が言うように鍵知ってたら暗号も
解析できちゃうんだけで完全じゃないけど
串動作と組み合わせれば解析が非常に困難になる）
そうそう、通信の暗号化とファイル名＆ファイルの暗号化は
別の暗号になるから、検索キーが公開されてても、
通信の中身はリバースエンジニアリングしないと解析できないよん。

基本的にプログラムのソースや通信プロトコルを公開する気はないし、
完全オリジナルのプロトコルで、通信全部を
暗号化（＆エラー検出を兼ねる）の予定だから、
怪しい接続は問答無用で弾けるはず。

基本はMX+Freenetだけど、暗号化や認証、データ圧縮補正系の
技術てんこ盛り＋串動作で解析不能にするわけやね。

もちろん手抜きしてるだけあってFreenetの匿名性には負けそうだし、
MXよりは不便でダウンが遅いだろうけど、目標は
MXの利便性・高速性とFreenetの匿名性を兼ね備えたシステムか。
もしどちらも実現できなかったら失敗ということで（ｗ