最近の P2P ソフトウェアはほとんどがデフォルトで UPnP を試行する。もちろん、（通常は）オプションで無効にできる。
うーん、俺もそれについて考えていた。最初のアイデアがおそらく最善だろう。そうすればサーバーデーモンを「ヘッドレス」で動かし、フロントエンドを自由に選べる。（フロントエンドの一つは、好みのウェブサーバーで動く PHP [または C++ CGI] プログラムにもできる）。
これにより、フロントエンドとバックエンドを別々のマシンで実行することも可能になる。（例：静的 IP を持つ Linux サーバーでヘッドレスで動かして受け取りを容易にし [IP モードでの支払い]、管理用のフロントエンドクライアントは Windows/Mac/その他で実行する）。フロントエンドは携帯電話のような CPU パワーの低いクライアントでも実行できる。nudge nudge 😉
もう一つ考えていることがある。シーディングだ。アプリはダウンロード前にプリシードしておくことができる。毎日プリシード済みの新しいアーカイブを準備できる。そうすれば IRC 接続は不要になる。（あるいはフォールバックとして使うこともできるだろう。IRC 接続のコードはまだ監査していない。いくつかのエクスプロイトを思いついたが、実際に存在するか確認するまでは言及したくない。）プリシーディングは TOR+IRC 問題も解決する。このシステムを I2P+TOR 上で動かしたい人が出てくるのは分かっている。😛
また、ブロックもプリシードしておけば、初回起動時にダウンロードする必要がなくなる。（28,000 ブロックを低速 ADSL でダウンロードするのは永遠にかかる。数百万ブロックになったらどれほどの時間がかかるか想像もつかない――一生かかるだろう。）
CVS アクセスか何かをもらえないだろうか？（無理なら、パッチを送ることはできるか？）手伝いたい。俺は主に Linux/BSD の人間で、その分野の専門知識を提供したい。
Cheers! 😊
サトシ・ナカモトの投稿（2009年12月9日 09:45 UTC）UPnPを試してみるのが楽しみだ。ほとんどのP2PクライアントはUPnPをデフォルトで有効にしているのだろうか？
管理インターフェースの最適な構成をまだ検討中だ。コマンドラインからバックグラウンドデーモンに通信して、受信トランザクションの照会や送金の開始を行う方法がよいかもしれない。その方が自動化に適している。あるいは80以外のポートでHTTPインターフェースを提供して、ブラウザーで管理する方法はどうだろうか？