Karmicads、時間を割いて詳しく返信してくれてありがとう。
Karmicadsの投稿（2010年5月2日02:15 UTC）ちょうど、freenet上の保存されたデータファイルと対話するための既存のプロトコルがあるようだ
ああ、Freenetの利用について言っていたのはそういう意味だったのか。ユーザーがFreenetを実行し、BitcoinがFreenetの制御プロトコルを使って通信する。しかし、Freenetの実行にはかなりのコンピューターリソース、特に帯域幅が必要であり、個人的にはそれだけの理由でFreenetノードを動かしたくない。だからこれをオプションにしたかった。
Karmicadsの投稿（2010年5月2日07:07 UTC）誤解させていたらすまない。ほかの人たちとよく検討したり合意したりしないままmagnetリンクを使うつもりはないし、ひとまず支持しているのも、すでに普及しているからではない。
既存の仕組みを再発明したくないという印象を受けた。そしてだからこそ普及度が重要で――他のソフトウェアでのmagnetリンクの既存の受容がプラスだった。
Karmicadsの投稿（2010年5月2日07:07 UTC）DataWraithの投稿（2010年5月1日13:40 UTC）magnetリンクはピアツーピアネットワーク上のファイルまたはファイル群を参照するために設計されたもので、よく知られているパラメーターはどれもファイル（ファイル名、サイズなど）を指す。
すまないがDataWraith、失礼ながら同意できない。まず、ハードドライブ上のファイルは、入れ子になった場所の階層的な名前空間、つまりドメインとディレクトリに対応づけられている。多くのP2Pネットワークのやり方が根本的に違うのは、名前空間が階層的でなく、扱うデータがアドレスではなく内容の一意性によって参照される点だ。対象がファイルであれ何であれ、決まった固定のアドレスによってではなく、固有の内容の同一性によって参照される。同一のファイルは本質的に同じものであり、P2Pアプリケーションは、複数のインスタンスを同じ対象への複数の供給元として使える。magnetのパラメーターは、どんなP2Pアプリケーションにもよく合っている。
分かった、すまない。ここで自分の言いたいことをはっきり伝えられていなかったようだ。magnetリンクがコンテンツを参照する仕組みは理解している。
おそらくメンタルモデルの違いだろう：自分にとって、Bitcoinのトランザクションは、適切な言葉がないが、ものというよりはプロセスだ。自分の認識では、magnetリンクはもの（通常はファイル――コンテンツハッシュまたは場所による）を参照するものであり、プロセスを参照するために使おうとするのは少し不自然に感じる。magnetリンクは取得しに行く必要があるものを特定するが、Bitcoinのトランザクションはリンク自体で完全に記述される（リンクをクリックした後に「はい、コインを送ります」と言う必要はあるが）。
自分には、magnetリンクを本来の目的ではないものに（悪）用することのように思える。magnetリンクはed2k://やfreenet://などの代替として、ファイルの取得方法を記述するために生まれたものだからだ。
Bitcoinリンクは、magnet:よりもmailto:に近いものであるべきだと思う。
Karmicadsの投稿（2010年5月2日07:07 UTC）いや、実際にはURNハンドラーだし、君の言う「重さ」に上限を決めたわけでもない。
ああ、自分の間違いだった、すまない。
Karmicadsの投稿（2010年5月2日07:07 UTC）いずれにせよ、これはまだ検討しているだけで、freenetをインストールせずにできればと思っている。（自分の予想どおり）freenetのウェブサーバー全体が必要でないなら、少なくとも、freenetとの読み書きに必要なコードの塊はずっと小さくて済むはずだ。
確か、ウェブサーバーはFreenet自体にかなり統合されている。よりシンプルなFCPプロトコルを使ってFreenetインスタンスと通信することもできるが、Freenet上のコンテンツの性質上、公開アクセス可能なインスタンスをホストする人は多くないので、自分で運用する必要がある。それを望むこと自体を悪く思ってはいないが、自分はやる気がないだけだ。むしろTORの隠しサービスをホストしたい――だからdetailsパラメーターにFreenet固有ではなく汎用的なフルURLを使うことを提案した。
Karmicadsの投稿（2010年5月2日07:07 UTC）
- address: bitcoinの送信先アドレス。人ごとに異なるアドレスを渡せるので、これは送信者の識別にもなりうる。
- amount（オプション）: 送る金額。
- message（オプション）: トランザクションを説明する短いメッセージ（Bitcoinクライアントのフィールドと同じ）。
- details（オプション）: トランザクションの詳細をエンコードしたURL。たとえばオンラインショップでの購入なら、購入の詳細にリンクできる。これ自体がフル機能のURLになるので、匿名性を保つためにfreenetやi2p、torにリンクすることもできる。
アドレスというのが何を指しているのか、よく分からない。bitcoinの署名が与える「アドレス」（場所というより名前に近い）以外には思い当たらない。すでに何かの別名を決めてあるのでない限り、人ごとに違うアドレスを渡せる理由が分からない。つまり、bitcoinノードの別名を符号化して変換する命名の仕組みを追加しようということ？ そういう意味なら、それほど手間をかけずにできるだろう。
まあ、bitcoinの署名のことだ。Bitcoinクライアントにそう表示されているから「アドレス」と呼んだ（「アドレスを変更」と表示される）。交換サイトが現在行っているように、異なるエイリアスを使うべきだと確かに考えていた：コインを送るアドレス（または署名、あるいは何でも）を受け取り、そのアドレスはあなたにだけ渡されたものなので、受取人は支払いがあなたからだと分かる。
エイリアスを変換するシステムはもちろん良いが、それはアドレス帳やmybitcoin.comなどで処理する方がよいと思う。
Karmicadsの投稿（2010年5月2日07:07 UTC）メッセージ：ここでURIのデータは扱いにくくなる。メッセージというのは、当然、人と人とのそれなりの量のやり取りのことで、URIそのものの中で届けることは想定されていなかった。受け取る側が何か文章を伝えたいなら、自分が公開している文書（つまり、リンクを載せている場所）で伝えればよい。送る側の文章は通常の経路を使えばいい。リンクがbitcoinの画面を呼び出し、そこにメモを書き込む欄があるのだから。受け取る側（支払いを受ける人）が伝えなければならないメッセージで、リンクを載せている文書の中では伝えられないものが何かあるだろうか？
そう、まさにその通りだ！ 送信側のテキストは通常のルートでよい。だが、送信されるテキストを事前に指定したい場合はどうか？
これにはmailto:リンクのアナロジーがある：誰かにメールを送ってほしい場合、使うべきsubjectも指定できる：mailto:alice@example.org?subject=Test。だから、例えばeBayで何かを売っている場合、「eBayオークション#12345の支払い」というメッセージを含むBitcoinリンクを買い手に渡せば、本人が入力する必要がなくなり、コードが#12345より暗号的な場合にミスを防げる。
Karmicadsの投稿（2010年5月2日07:07 UTC）詳細：自分は最初から、URIスキームが、必須のパラメーターで渡される基本的な情報を補える、より豊かなデータ構造を持つ文書を参照できることが望ましいと主張してきた。それらの文書の置き場所の案も出した。それにはアクセスのしやすさの問題が伴ったが、解決できれば、bitcoinノードの匿名性を高め、P2Pでない、つまり階層的な名前空間への依存を避けられる。美しいネットワークのアドレス指定のプロトコルを、後退した、劣った、ひどく醜いものに（あるいは無理やり継ぎ足して）写し替えるなど、すべての主体に固定の場所という発想を押しつけ、移動すれば組み込まれた関連づけを全部失うようなものだ。自分には、美しい石造りの建物に安っぽいプラスチックの塗料を、それも明るい緑色の塗料を塗るのと同じくらい無神経に思える。パラメーターにURLを使うことこそ、自分が避けたいぶち壊しだ。URLはURNではなく、それが指す名前空間は階層的で、最終的には固定のIPに置かれていなければならないからだ。
すまない、URI、URLなどの用語をアドレスバーに入力するからつい混同して使いがちだ %)。混乱させたなら申し訳ない。
ここで自分が望んでいたのは、この追加情報を汎用的にすることだ。いくつかの例で明確になるかもしれない：
https://www.myonlineshop.com/purchaseDetails/123456http://pastie.org/942292- freenet://[Freenet上のリソース]/
http://kpvz7ki2v5agwt35.onion/wiki/index.php/PurchaseDetailsHere- magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
リンクの作成者が追加情報の置き場所を選び、受取人がFreenet/Tor/I2Pをインストールするほど補足情報が必要かどうかを判断する。これがリンク自体に短いメッセージを含める理由の一つだ：追加情報はトランザクションに不可欠であるべきではない。
Karmicadsの投稿（2010年5月2日07:07 UTC）この 「匿名性を保つためにfreenetやi2p、torにリンクすることもできる」という点について言えば、君は明らかに、あまりよく考えていない。freenetにリンクするだけでいいのなら、最初からfreenetを、URIが参照する置き場所そのものとして組み込んでも同じことだ。
だが、それだとFreenetの使用が必須にならないか？ もっと柔軟であってほしい。
また、オンラインショップを運営する場合、Freenetをインストールさせるよりも、自分のウェブサイトで詳細を確認してもらう方がよい。Freenetの評判を考えると、ショップの評判がFreenetと結びつくのは望ましくないかもしれない。
Karmicadsの投稿（2010年5月2日07:07 UTC）そこが問題なのだ。freenetにファイルを置いておくだけで、普通のウェブサイト上のURLやURNで誰でも取り出せると期待することはできない。訪れた人がそのリンクを扱うクライアントソフトウェアを持っていない限り、そのリンクが示す参照は役に立たない。
そう。これがHTTP(S)のURLも許可すべきもう一つの理由だ。理解が正しければ、トランザクションにFreenetの使用を必須にしたいようだが、それには強く反対する。
Karmicadsの投稿（2010年5月2日07:07 UTC）http/sは階層的な名前空間の上で動き、P2Pのクライアントは階層的でない名前空間の上で動くので、一つのパラメーターで両方を相互に指すことはできない。物理的な場所に自分の身元を結びつけてしまった後で、匿名になろうと決めても遅すぎる。
すべてのトランザクションに完璧な匿名性が必要なわけではない。寄付を受けるオープンソースプロジェクトやオンラインショップを考えてみてほしい。（a）短いメッセージパラメーターで提供できる以上の詳細が必要で、（b）完全に匿名でありたいなら、FreenetやTorやI2PのURL（またはURN？――ややこしい :-/ ）を指定すればよい。追加の匿名性が不要なら、Freenet/Tor/I2P/その他を運用する手間をかける必要はない。
Karmicadsの投稿（2010年5月2日07:07 UTC）誤解していたら申し訳ない、DataWraith。だが君は、二つの名前空間のモデルの違いも、それぞれの長所と短所も、よく分かっていないように見える。自分は今でも、ほかのどんな方式でも喜んで検討する。君の批判を頭ごなしに退けているわけでも、自分の好みを標準にすべきだと言い張っているわけでもない。何にせよ、できる限り最良のURIスキームを作りたいだけだ。いずれにしても、考えてくれてありがとう。
まあ、みんな同じ目標に向かっている。可能な限り最良のシステムに到達できることを願う。:-)
詳しく説明してくれて、自分の提案に辛抱強くつきあってくれて、ありがとう。