やあ、DataWraith
DataWraithの投稿（2010年5月1日13:40 UTC）magnetリンクをすでにある程度普及しているからという理由だけで使っても、欠点を上回るメリットはないと思う。
誤解させていたらすまない。ほかの人たちとよく検討したり合意したりしないままmagnetリンクを使うつもりはないし、ひとまず支持しているのも、すでに普及しているからではない。正直なところ、うわべの人気には、できるだけ左右されたくない。自分の考えでは、magnet URIを検討する理由は、明記された目的と仕様の草案 (http://magnet-uri.sourceforge.net/magnet-draft-overview.txt)にある。
MAGNETは策定中のURI仕様であり、ウェブサイトが、ローカルのユーティリティープログラムの提供する機能とシームレスに連携できるようにするための、標準的な慣行と実装コードの集まりである。ある意味では、FreenetとEDonkey2000のピアツーピアネットワークがそれぞれ使う「freenet:」と「ed2k:」のURIスキームを、特定の企業やプロジェクトに依存しない形で一般化したものと考えることもできる。
明記された目的は、まさに、ウェブサイトがローカルのユーティリティープログラムの機能とシームレスに連携できるようにすることだ。特定の企業に依存せず、車輪の再発明を避け、ほかのURIスキームとのこれ以上の衝突を避けることを意図している。W3Cの標準にも厳密に準拠していて、magnetの約束事を使うスキームなら、その厳密さを受け継ぐことになる。
DataWraithURIの形式についての注記：
確かに、「:」のすぐ後に「?」が来るのは少し奇妙に見えるが、関連するURL/URIのRFCを私が読んだ限りでは、推奨される共通のURI構文にうまく合っている。（パラメーターが個々のローカルアプリに渡される方法ともうまくかみ合う。）
参考までに、EDonkeyのURIは、RFC 1738と2396の多くの条項に違反している。階層的でない名前空間の先頭に「//」を使っていることや、（エスケープされていない場合に）不正または非推奨の文字を使っていることなどだ
パラメーターの名前と値は、正式には、HTTPのウェブフォームのGET送信のクエリー文字列と同じように、www-formencodedされるべきである。ただし実際には、HTMLの仕様やRFC 1738を厳密に読めばエンコードすべきとされる文字（「.」や「:」など）の一部は、エンコードされていないようだ。
接頭辞「x.」は、アプリケーション固有の新しいパラメーターを試すために予約されている。「x.」で始まらないパラメーターは、正式なMAGNET仕様によってのみ定義される。
ほかに考えられるパラメーターとしては、P2Pで見つからないコンテンツのための「代替の所在」、P2Pシステム固有の識別子（ed2k、sig2dat、freenet）、そのほかのトピックの修飾子（「長さ」）などがある。これらはまだ設計されておらず、意見を求めている。
magnetリンクはピアツーピアネットワーク上のファイルまたはファイル群を参照するために設計されたもので、よく知られているパラメーターはどれもファイル（ファイル名、サイズなど）を指す。
すまないがDataWraith、失礼ながら同意できない。まず、ハードドライブ上のファイルは、入れ子になった場所の階層的な名前空間、つまりドメインとディレクトリに対応づけられている。多くのP2Pネットワークのやり方が根本的に違うのは、名前空間が階層的でなく、扱うデータがアドレスではなく内容の一意性によって参照される点だ。対象がファイルであれ何であれ、決まった固定のアドレスによってではなく、固有の内容の同一性によって参照される。同一のファイルは本質的に同じものであり、P2Pアプリケーションは、複数のインスタンスを同じ対象への複数の供給元として使える。magnetのパラメーターは、どんなP2Pアプリケーションにもよく合っている。
DataWraith例で示すMAGNET URI：
(1)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
意味：与えられたURI（具体的にはURN）が示す「完全一致トピック」（xt）に関する選択肢を表示せよ
(2)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3
意味：この完全一致トピックに関する選択肢を表示せよ。ただし利用者の便宜のため、含まれている（検証されていない）「表示名」を使え
(3)
magnet:?kt=martin+luther+king+mp3
意味：文字列で与えられた「キーワードトピック」（kt）に関する選択肢を表示せよ
(4)
magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7
意味：与えられた二つの完全一致トピックに関する選択肢を表示せよ
(5)
magnet:?mt=
http://weblog.foo/all-my-favorites.rss意味：与えられたURIから取得できる「マニフェストトピック」（mt）に関する選択肢を表示せよ。これはURNでもよい。マニフェストトピックには、ほかの項目の一覧が含まれる。
うわっ！ Bitcoinクライアントを起動するだけの軽量なURLハンドラから、Freenetを必要とするところまで行くのは少し飛躍だ。これは本当にオプションであるべきだ。
いや、実際にはURNハンドラーだし、君の言う「重さ」に上限を決めたわけでもない。それより自分は、堅牢であることと、自分自身が身動きの取れない状態に追い込まれないことのほうを気にする。後方互換性と将来の拡張性を最初から考えておくための手間は、自分の考えでは小さな代償だ。いずれにせよ、これはまだ検討しているだけで、freenetをインストールせずにできればと思っている。（自分の予想どおり）freenetのウェブサーバー全体が必要でないなら、少なくとも、freenetとの読み書きに必要なコードの塊はずっと小さくて済むはずだ。それから、URIには当然、このfreenetの機能をオプションのパラメーターとして含めるべきだ。そうすれば、指定されなくても、基本的な取引に必要な情報はそのまま有効になる。URIを公開するときに使うことは必須にならないが、使われた場合には、ハンドラーはそのパラメーターを受け取れるようにしておくべきだ。そうでなければ、君が提案しているオプションの選択は、互換性のない二つの別々のURIスキームのどちらかを選ぶことになってしまう。念には念を入れよ、だ。
DataWraithただ、トランザクションに追加情報を付けられるのは確かにとても良い。ecの最初の投稿と、さらなる詳細が必要だという点を踏まえ、以下のURLパラメーター（あるいはその短縮版）を持つべきだと思う。
- address: bitcoinの送信先アドレス。人ごとに異なるアドレスを渡せるので、これは送信者の識別にもなりうる。
- amount（オプション）: 送る金額。
- message（オプション）: トランザクションを説明する短いメッセージ（Bitcoinクライアントのフィールドと同じ）。
- details（オプション）: トランザクションの詳細をエンコードしたURL。たとえばオンラインショップでの購入なら、購入の詳細にリンクできる。これ自体がフル機能のURLになるので、匿名性を保つためにfreenetやi2p、torにリンクすることもできる。
アドレスというのが何を指しているのか、よく分からない。bitcoinの署名が与える「アドレス」（場所というより名前に近い）以外には思い当たらない。すでに何かの別名を決めてあるのでない限り、人ごとに違うアドレスを渡せる理由が分からない。つまり、bitcoinノードの別名を符号化して変換する命名の仕組みを追加しようということ？ そういう意味なら、それほど手間をかけずにできるだろう。
金額：うん、言うまでもない。
メッセージ：ここでURIのデータは扱いにくくなる。メッセージというのは、当然、人と人とのそれなりの量のやり取りのことで、URIそのものの中で届けることは想定されていなかった。補足の文書を参照する必要が出てくるのは、ここからだ。支払う側は、ソフトウェアの画面（単体のプログラムでも、Firefoxのアドオンでも）でメッセージを送れる。リンクは最低限、ソフトウェアに渡さなければならない受取人と金額を示す。受け取る側が何か文章を伝えたいなら、自分が公開している文書（つまり、リンクを載せている場所）で伝えればよい。送る側の文章は通常の経路を使えばいい。リンクがbitcoinの画面を呼び出し、そこにメモを書き込む欄があるのだから。受け取る側（支払いを受ける人）が伝えなければならないメッセージで、リンクを載せている文書の中では伝えられないものが何かあるだろうか？ 支払う側が伝えなければならないメッセージで、画面ではできないのに、リンクをクリックすればできるものが何かあるだろうか？ もしあるなら、リンクがpostやgetのようなメソッドを呼び出すことになる。それはhttp/sだけの機能で、専用のURIスキームを持つ意味がなくなる。PostとGetの機能は、TCP/IPの階層的な名前空間や、物理的なファイルパス名の中で扱う必要がある。
詳細：自分は最初から、URIスキームが、必須のパラメーターで渡される基本的な情報を補える、より豊かなデータ構造を持つ文書を参照できることが望ましいと主張してきた。それらの文書の置き場所の案も出した。それにはアクセスのしやすさの問題が伴ったが、解決できれば、bitcoinノードの匿名性を高め、P2Pでない、つまり階層的な名前空間への依存を避けられる。美しいネットワークのアドレス指定のプロトコルを、後退した、劣った、ひどく醜いものに（あるいは無理やり継ぎ足して）写し替えるなど、すべての主体に固定の場所という発想を押しつけ、移動すれば組み込まれた関連づけを全部失うようなものだ。自分には、美しい石造りの建物に安っぽいプラスチックの塗料を、それも明るい緑色の塗料を塗るのと同じくらい無神経に思える。パラメーターにURLを使うことこそ、自分が避けたいぶち壊しだ。URLはURNではなく、それが指す名前空間は階層的で、最終的には固定のIPに置かれていなければならないからだ。
この 「匿名性を保つためにfreenetやi2p、torにリンクすることもできる」という点について言えば、君は明らかに、あまりよく考えていない。freenetにリンクするだけでいいのなら、最初からfreenetを、URIが参照する置き場所そのものとして組み込んでも同じことだ。そこが問題なのだ。freenetにファイルを置いておくだけで、普通のウェブサイト上のURLやURNで誰でも取り出せると期待することはできない。訪れた人がそのリンクを扱うクライアントソフトウェアを持っていない限り、そのリンクが示す参照は役に立たない。URIハンドラーがfreenetの名前空間を指せるようにできるのなら、最初からファイルをそこに置くほうがずっとよいと思う。http/sは階層的な名前空間の上で動き、P2Pのクライアントは階層的でない名前空間の上で動くので、一つのパラメーターで両方を相互に指すことはできない。物理的な場所に自分の身元を結びつけてしまった後で、匿名になろうと決めても遅すぎる。
誤解していたら申し訳ない、DataWraith。だが君は、二つの名前空間のモデルの違いも、それぞれの長所と短所も、よく分かっていないように見える。自分は今でも、ほかのどんな方式でも喜んで検討する。君の批判を頭ごなしに退けているわけでも、自分の好みを標準にすべきだと言い張っているわけでもない。何にせよ、できる限り最良のURIスキームを作りたいだけだ。いずれにしても、考えてくれてありがとう。
編集:
「金額：うん、言うまでもない。」という自分のコメントについては、撤回する。リンクを支払いのきっかけとしてだけ考えていたが、もちろん、金額やほかのパラメーターが空欄なら、支払う側の求めに応じて支払いを始めるための、相手を示すリンクとして働くのが既定になるべきだ。簡単な寄付ボタンなら、パラメーターは一つで済み、転送もログインも確認も、金額の計算や通貨の変更も要らずに、すぐに送れる。クレジットカードを持っていなくても、自分の送金が、馬で運ぶ郵便にまで置いていかれるような遅さを味わわずに済む。（ざまあみろ、PlayPal）。それと、DataWraithが提案した命名の別名、いわゆる（アドレスを持つ）という案は、君の意図がそういうことならだが、自分のbitcoinにぜひ実装する価値がある。😉