Bitcoin 用 URI スキーム
こんにちは、ビットコインのシステムに興味を持ち、一つアイデアがある：
ビットコインアドレスは、例えばトレントのマグネットリンク (http://en.wikipedia.org/wiki/Magnet_URI_scheme)のような URI スキーム (http://en.wikipedia.org/wiki/URI_scheme)を実装することで改善できるだろう。
つまり、1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ の代わりに、より明確に bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ と表記でき、さらにブラウザーでこのようなリンクのクリックをビットコインクライアントにリダイレクトするよう設定できる。これにより、ホームページに「寄付ボタン」を、ウェブショップに「支払いボタン」を実装できるようになるだろう。
IP を含める必要がある場合、URI では bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ と記述できる。希望すれば金額も bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ のように指定できる（もちろんユーザーがセキュアなビットコインクライアントで確認するためのものだ）。
以上、私の 0.02 ฿（気に入らなければ bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ に返してくれ）
URI スキームは QR コードを使ったモバイルウォレットの実装にも役立つだろう。X bitcoin を払いたい友人が Bitcoin アドレスを手動で入力する必要がなく、自分の携帯電話の画面を撮影するだけで済むようになる。
ああ、俺もまったく同じことを考えていた。マグネットリンク方式は最高だろう。😁
販売時点で便利だろうな。レジが Bitcoin アドレスと金額をエンコードした QR コードを画面に表示し、携帯電話で撮影するのだ。
それはものすごく素晴らしいだろうな……😊
このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザー機能の実装の可能性を調査しているところだ。まずこれを試して、Firefox アドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。
これが実現する前に、URI がどのような形式を取るかについてコンセンサスが必要だ。URI スキームについて少し調査したが、W3C の承認なしのほとんどのアプローチは好ましくないとされている。W3C が暫定的な URI スキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネット URI のようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメーターがある。基本的に、アプリケーション固有のパラメーターの前に x を付けるだけだ。例：xbitcoin1:?
新しいトップレベル URI スキームの実装を試みないのが良いかもしれない。普遍的に認識されていなければ、即興的な手法と見なされるからだ。マグネットシステムの採用はこれを回避するが、マグネット自体も非公式の未登録スキームだ。マグネットの利点は共有可能でオープンなことだ。
これは非常に良さそうに見えるかもしれない。bitcoin は結局 P2P アプリケーションであり、そのネットワークは似た原理で動作しているからだ。しかし、リンクをクリックする人が bitcoin ユーザーでない場合はどうか？ 既存のネットワークに含まれない情報、例えば販売する商品、配送情報、その他の問題を組み込みたい場合はどうか。bitcoin はトランザクション自体のみを処理するという理解なので、ユーザーは他のすべての取り決め、契約、コミュニケーションを bitcoin とは独立に行う必要がある。ここで匿名性が損なわれる。従来の「階層的なハードワイヤード、または非匿名の技術」に頼る傾向があるからだ。これは bitcoin への批判ではまったくない。bitcoin は素晴らしいトランザクション方法だ。しかし、トランザクションはコインの片面にすぎない（このひどいダジャレを許してくれ）。😄
URI の調査過程で freenet と彼らが使うマグネットに似たシステムを思い出し、結局そこに戻ってチェックした。freenet が情報保存を意図したユーザー/アイデンティティ空間であるなら、各ユーザーに固有の人間可読なデータファイルのリポジトリとしても使えないだろうか。トランザクションの補足に使いたい任意の形式のデータを組み込める。これを URI からアプリケーション固有のリッチなデータベースに接続するために使えないだろうか。bitcoin ノードが実際のトランザクションを処理する間、freenet ノードが個別のデータの提示を処理する。
これにより、すべてが同じ種類の暗号 P2P インフラストラクチャの下に保たれ、アプリケーション固有のコンテキストの無限の多様性が可能になるはずだ。ユニークな URI ハッシュキーは、freenet+bitcoin のハッシュの組み合わせから生まれ、freenet キーで暗号化されたファイルは bitcoin キーで復号して見つけ、bitcoin ノードにはその逆でアドレスできるのではないか。正しいだろうか？ もちろん、一方で実名を使えば、もう一方でも実名が明らかになるだろう。
いずれにしても、何らかの方法があるはずだ。繰り返すが、freenet も未登録の URI スキームを使っているが、マグネットの変形が採用されればそれは問題にならない。残る疑問は、bitcoin が正式に認められた通貨として非常に正当なものになることを望むなら、他のすべてのインターネットプロトコルへの厳格な準拠が望ましいかもしれないということだ。マグネット/freenet のような URI スキームの登録を妨げるものは特に見当たらなかった。すべてを検索してはいないが、既に存在するかもしれない。そうでなければ、なぜ登録しないのか？
URI スキームの分類（どの種類のマグネットなのか、正式/公式にするかどうか）とレイアウトの形式について合意する必要がある：
URI の構成要素
これは Mozilla が URI のパース時に考慮する規則に関するものだ。
典型的なマグネット URI はこのようになる：
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
freenet URI はこのようなものだ：
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
認識されるためには freenet プログラムをインストールする必要があり、これにはリソースを localhost のアイデンティティ空間のアイテムとして認識する Java 搭載のウェブサーバーが含まれる。つまり、ブラウザーからは freenet 全体が自分のマシン上にあるように見える。ユーザーがウェブサーバーを実行せずにこのアイデンティティ空間をアドレス可能にできるかは分からないが、サーバーはウェブページの提供と localhost をトップレベルドメインとして認識するためだけに必要だと思われる。「http:」は freenet URI 自体が特別なものではないことを示しているが、IP アドレス（localhost）は確かに特別だ。プログラムがウェブサーバーを組み込まずに freenet ユーザー空間にアクセスでき、ユニバーサルリンクはマグネット URI として作成できるのではないかと思う。bitcoin がインストールされていない人に対して、そのリンクの訪問者を bitcoin の SourceForge ダウンロードにリダイレクトするデフォルトのフォールバックを URI に持たせる方法は分からない。コード内で実装し、bitcoin の存在を記録するために cookie や環境変数を設定する必要があるかもしれない。
この調査中に訪れた他の関連サイト：
http://infomesh.net/2001/09/urischemeshttp://www.search.com/reference/Magnet:_URI_schemehttp://magnet-uri.sourceforge.net/http://magnet-uri.sourceforge.net/magnet-draft-overview.txthttp://www.w3.org/Addressing/schemeshttp://www.w3.org/Addressing/schemes#Registration
アイデア/コメント/フィードバックは歓迎する。😉 Steve
これが実現する前に、URIがどんな形を取るかについて合意が必要だ。[snip] ……最も適したスキームは、特定のアドレスではなく、コンテンツの一意性の産物であるハッシュによってリソースを見つけるように設計されたmagnet URIのようだ。 [snip] magnetの美点は、共有可能でその意味で開かれていることだ。
magnet リンクをすでにある程度普及しているからという理由だけで使っても、欠点を上回るメリットはないと思う。magnet リンクはピアツーピアネットワーク上のファイルまたはファイル群を参照するために設計されたもので、よく知られているパラメーターはどれもファイル（ファイル名、サイズなど）を指す。bitcoin はアプリケーション固有の xBitcoin パラメーターに頼ることになるし、ファイルと bitcoin トランザクションを 1 つのリンクに混在させたいわけでもない。だから、独自の別フォーマットを使わない説得力のある理由はとくにない。そもそも magnet リンク自体も公式には認知されていないしな。
URIを調べる過程でfreenetと、彼らが使うmagnet風のシステムを思い出して、また見に行ってみた。[snip] これを使えば、出版者自身のウェブサイトの機能やビジネスシステム向けに設計された、アプリケーション固有データのリッチなデータベースにURIを連結できないか？bitcoinノードが実際のトランザクションを処理する一方で、freenetノードが個別に提示されるデータを処理する。
うわっ！Bitcoin クライアントを起動するだけの軽量な URL ハンドラから、Freenet を必要とするところまで行くのは少し飛躍だ。これは絶対にオプションにすべきだ。
ただ、トランザクションに追加情報を付けられるのは確かにとても良い。ec の最初の投稿と、さらなる詳細が必要だという点を踏まえ、以下の URL パラメーター（あるいはその短縮版）を持つべきだと思う。
- address: bitcoin の送信先アドレス。人ごとに異なるアドレスを渡せるので、これは送信者の識別にもなりうる。
- amount（オプション）: 送る金額。
- message（オプション）: トランザクションを説明する短いメッセージ（Bitcoin クライアントのフィールドと同じ）。
- details（オプション）: トランザクションの詳細をエンコードした URL。たとえばオンラインショップでの購入なら、購入の詳細にリンクできる。これ自体がフル機能の URL になるので、匿名性を保つために freenet や i2p、tor にリンクすることもできる。
速報：…
ちょうど、freenet 上の保存されたデータファイルと対話するための既存のプロトコルがあるようだ。😄 ＜やった！＞ 😄
申し訳ない、自分が提案した freenet URI 機能に合意しなければならないとは思っていない。ただ、実験目的であっても非常に簡単に組み込めることがワクワクするということだ。事前設定された freenet サーバーにアドレスするだけでうまくいくはずだが、既存のコードを少し修正して直接 freenet にアドレスすることもできるかもしれない（正式な freenet インストールに含まれる暗黙のウェブサーバーなしで）。この FCP コードをブラウザーアドオンに含めることで、フルの freenet HTTP サーバーのオーバーヘッドなしに、アドレッシングと通信の機能だけを組み込めるかもしれない。この時点では、freenet ウェブサーバーはクライアントが freenet をブラウジングするためだけに必要で、ノードのサービスには不要だと想定している。Bitcoin は既に同様の P2P ネットワークにアドレスしているので、bitcoin サーバーに freenet の問い合わせをさせるのはどの程度難しいだろうか？ そのようなトリックを JSON インターフェースに含めることはできるだろうか？
参照：http://new-wiki.freenetproject.org/FCPv2
つまり、自由に freenet からデータを取り出し、freenet にデータを投稿できるようだ。 非常に興味深い。
それとは別に、freenet URI 統合のプロキシや回避策を探す過程で、ISP が VoIP/SIP をブロックしているという無関係な問題を解決できたと思う（ローカルの電話会社でもあるので。そう、もうすぐプロバイダーを変更する）。VoIP が欲しいのだが、反競争的なクソ ISP がモデムのファームウェア（内蔵の 2 ポートアナログ電話アダプター付き）を無効化している。この回避策（Tor）でうまくいくことを願っているが（期待はしていない）。Link2VoIP、もし読んでいるなら、あなたに注目している。😉
Karmicads、詳細な返信をありがとう。
Karmicadsの投稿（2010年5月1日 17:15 UTC）ちょうど偶然にも、freenetに保存されたデータファイルと正確にやり取りするための既存のプロトコルがあるようだ
ああ、Freenet の利用について言っていたのはそういう意味だったのか。ユーザーが Freenet を実行し、Bitcoin が Freenet の制御プロトコルを使って通信する。しかし、Freenet の実行にはかなりのコンピューターリソース、特に帯域幅が必要であり、個人的にはそれだけの理由で Freenet ノードを動かしたくない。だからこれをオプションにしたかった。
既存の仕組みを再発明したくないという印象を受けた。そしてだからこそ普及度が重要で――他のソフトウェアでの magnet リンクの既存の受容がプラスだった。
すまないが、敬意を込めつつ、同意しかねる。最初の問題は、ハードドライブ上のファイルがネストされた場所の階層的な名前空間、つまりドメインとディレクトリにマッピングされていることだ。多くの P2P ネットワークのアプローチの根本的な違いは、名前空間が階層的でなく、サポートするデータがアドレスではなくコンテンツの一意性によって参照されることだ。ターゲットがファイルであろうと何であろうと、特定の固定アドレスではなく、固有のコンテンツのアイデンティティによって参照される。同一のファイルは本質的に同じアイデンティティであり、P2P アプリケーションは同一アイテムへの複数のフィードとして複数のインスタンスを使用できる。magnet のパラメーターはあらゆる P2P アプリケーションに適している。 了解、ここで自分の言いたいことを完全に明確にしていなかったようだ。magnet リンクがコンテンツを参照する仕組みは理解している。
おそらくメンタルモデルの違いだろう：自分にとって、Bitcoin のトランザクションは、適切な言葉がないが、ものというよりはプロセスだ。自分の認識では、magnet リンクはもの（通常はファイル――コンテンツハッシュまたは場所による）を参照するものであり、プロセスを参照するために使おうとするのは少し不自然に感じる。magnet リンクは取得しに行く必要があるものを特定するが、Bitcoin のトランザクションはリンク自体で完全に記述される（リンクをクリックした後に「はい、コインを送ります」と言う必要はあるが）。
自分には、magnet リンクを本来の目的ではないものに（悪）用することのように思える。magnet リンクは ed2k://や freenet://などの代替として、ファイルの取得方法を記述するために生まれたものだからだ。
Bitcoin リンクは、magnet:よりも mailto:に近いものであるべきだと思う。
そうだ、すまない。
確か、ウェブサーバーは Freenet 自体にかなり統合されている。よりシンプルな FCP プロトコルを使って Freenet インスタンスと通信することもできるが、Freenet 上のコンテンツの性質上、公開アクセス可能なインスタンスをホストする人は多くないので、自分で運用する必要がある。それを望む気持ちは否定しないが、自分はやりたくない。むしろ TOR の隠しサービスをホストしたい――だから details パラメーターに Freenet 固有ではなく汎用的なフル URL を使うことを提案した。
アドレスという意味がよく分からないが、Bitcoin の署名で提供される「アドレス」以外を指しているのか。すでにエイリアスが定義されていない限り、異なる人に異なるアドレスを渡す方法が分からない。つまり、Bitcoin ノードのエイリアスをエンコードして変換する命名システムを追加することを提案しているのか？それはそれほど手間なくできるだろう。 まあ、Bitcoin の Signature のことだ。Bitcoin クライアントにそう表示されているから「アドレス」と呼んだ（「アドレスを変更」と表示される）。交換サイトが現在行っているように、異なるエイリアスを使うべきだと確かに考えていた：コインを送るアドレス（または署名、あるいは何でも）を受け取り、そのアドレスはあなたにだけ渡されたものなので、受取人は支払いがあなたからだと分かる。
エイリアスを変換するシステムはもちろん良いが、それはアドレス帳や mybitcoin.com などで処理する方がよいと思う。
そう、まさにその通りだ！送信側のテキストは通常のルートでよい。だが、送信されるテキストを事前に指定したい場合はどうか？
これには mailto:リンクのアナロジーがある：誰かにメールを送ってほしい場合、使うべき subject も指定できる：mailto:alice@example.org?subject=Test。だから、例えば eBay で何かを売っている場合、「eBay オークション#12345 の支払い」というメッセージを含む Bitcoin リンクを買い手に渡せば、本人が入力する必要がなくなり、コードが#12345 より暗号的な場合にミスを防げる。
すまない、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 をインストールするほど補足情報が必要かどうかを判断する。これがリンク自体に短いメッセージを含める理由の一つだ：追加情報はトランザクションに不可欠であるべきではない。
だが、それだと Freenet の使用が必須にならないか？もっと柔軟であってほしい。
また、オンラインショップを運営する場合、Freenet をインストールさせるよりも、自分のウェブサイトで詳細を確認してもらう方がよい。Freenet の評判を考えると、ショップの評判が Freenet と結びつくのは望ましくないかもしれない。
そう。これが HTTP(S)の URL も許可すべきもう一つの理由だ。理解が正しければ、トランザクションに Freenet の使用を必須にしたいようだが、それには強く反対する。
すべてのトランザクションに完璧な匿名性が必要なわけではない。寄付を受けるオープンソースプロジェクトやオンラインショップを考えてみてほしい。（a）短いメッセージパラメーターで提供できる以上の詳細が必要で、（b）完全に匿名でありたいなら、Freenet や Tor や I2P の URL（または URN？――ややこしい :-/ ）を指定すればよい。追加の匿名性が不要なら、Freenet/Tor/I2P/その他を運用する手間をかける必要はない。
まあ、みんな同じ目標に向かっている。可能な限り最良のシステムに到達できることを願う。:-)
丁寧な説明と、自分の提案への忍耐に感謝する。
freenet URIはこのようなものだ：
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
そうだな、同じ方法で簡単にできる。例えば:
http://127.0.0.1:8330/?to=
Bitcoin は JSON-RPC のポート 8332 と同様に、ローカルループバックのポート 8330 で応答できる。HTTP 応答を返すことになる。
DataWraithの投稿（2010年5月2日 02:13 UTC）Bitcoin リンクは、magnet:よりも mailto:に近いものであるべきだと思う。
それは可能だと思う。
Bitcoin が HTTP 応答で HTML の UI をユーザーに表示して処理することも可能だが、ユーザーとしては、ウェブサイトが騙そうとしているのか、本当に自分の Bitcoin サーバーと通信しているのか疑問に思うだろう。
HTTP 応答は、JavaScript の戻るボタンに相当する HTML にして、元のページに戻すだけでよいだろう。その後、Bitcoin が「ビットコインを送る」ダイアログを、送付先のビットコインアドレスと金額が既に入力された状態でポップアップ表示する。メールアドレスが入力された新規メールがポップアップする mailto:リンクと同じように動作する。
127.0.0.1 のループバックはマシン上のどのユーザーからもアクセス可能で、ユーザーごとの分離はないが、ダイアログのフィールドを事前入力する利便性機能を提供するだけなので問題ない。送信を押す必要はまだある。スペースや Enter を入力している最中にフォアグラウンドに飛び出してこないように、送信ボタンが選択されていない状態にする必要がある。
ほら、同じやり方で簡単にできる：
http://127.0.0.1:8330/?to=;amount=
非常に実用的な回答だ。気に入った。
しかし、ここで説明されている IP/Bitcoin アドレスの複合 URI（URN？ URL？）スキームとはどのように連携するのだろうか？ [link]topic 158]
ほぼ 1ヶ月経ってしまったが、申し訳ない。
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
または
http://127.0.0.1:8330/?to=
しかし、リンクがすでに入力を代行してくれる以上、ビットコインアドレスの代わりにドメインアドレスを使うことにそれほどの利点があるとは思えない。ビットコインアドレスであれば、ユーザーは身元不明の支払いを送ることができない。正しいビットコインアドレスが与えられるまで支払いを送ることができないのだ。
ドメインで送信する良い点は、送信先を視覚的に確認できることだ。
より重要な問題は、ブラウザーが 127.0.0.1 に接続することを許可されていない場合はどうなるかということだ: topic 63
そして、もしそうだとすると、127.0.0.1 が含まれていた Freenet リンクの例はどうなるのだろうか？
しかし、リンクがすでに入力を代行してくれる以上、ビットコインアドレスの代わりにドメインアドレスを使うことにそれほどの利点があるとは思えない。ビットコインアドレスであれば、ユーザーは身元不明の支払いを送ることができない。正しいビットコインアドレスが与えられるまで支払いを送ることができないのだ。
ドメインで送信する良い点は、送信先を視覚的に確認できることだ。
Bitcoin アドレスの複雑さをカジュアルユーザーから隠すことは良いことだと思う。それが無理なら、アドレストランザクションに観察可能だが変更不可能なメッセージを埋め込めるようにすべきだ。これが技術的に実現不可能な理由があるだろうか？
サトシ・ナカモトの投稿（2010年6月15日 15:15 UTC）より重要な問題は、ブラウザーが 127.0.0.1 に接続することを許可されていない場合はどうなるかということだ: topic 63
そして、もしそうだとすると、127.0.0.1 が含まれていた Freenet リンクの例はどうなるのだろうか？
問題を誤解していると思う。私のブラウザーは常に 127.0.0.1 にアクセスできる（奇妙な IE の設定やウイルスがなければ）。URL バーにアドレスを入力するかリンクをクリックすれば、正常に動作する。しかし、JavaScript を使ってドメイン間（または同じドメインの異なるポート間）で POST リクエストを完了することはできない。
このリンクをクリックしてみてほしい：
http://127.0.0.1/
おそらく何も表示されないだろう（システムで Web サーバーを動かしていない限り）が、ブラウザーは喜んでそこに移動しようとする。
XMLHTTPRequest が、あのスレッドで議論していたものだ。
ええ、クロスドメインの JavaScript 呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1 上にない JavaScript から 127.0.0.1 を呼び出すことはできません。考えてみると、ブラウザーが悪意のあるクロスドメイン JavaScript に人々の Facebook ページを変更させたら、かなり面白いことになりますね。
ええ、クロスドメインの JavaScript 呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1 上にない JavaScript から 127.0.0.1 を呼び出すことはできません。考えてみると、ブラウザーが悪意のあるクロスドメイン JavaScript に人々の Facebook ページを変更させたら、かなり面白いことになりますね。
http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> のような場所を指す iframe を置く方法が考えられる。その iframe の中には小さなビットコインのインターフェースが表示され、いくらを誰に支払うかと、決済の確定・取消のボタンが並ぶ。確定すればコインがそのドメインに送られ、クエリ文字列の return に指定した場所へリダイレクトされる。ビットコイン側で ?paid=true や ?paid=false をリダイレクト先に付けておけば、ドメイン側の戻り先スクリプトが受領を正しく確認したり、注文を取り消したりできる。
Edit: 決済を確定する前に、このビットコインのインターフェースでパスワードも要求すべきだ。さもないと誰かのポート 8330 が開いているのを走査され、自動的に支払いを送らされてしまう。
Edit: 決済を確定する前に、このビットコインのインターフェースでパスワードも要求すべきだ。さもないと誰かのポート 8330 が開いているのを走査され、自動的に支払いを送らされてしまう。
問題を誤解していると思う。私のブラウザーは常に 127.0.0.1 にアクセスできる（奇妙な IE の設定やウイルスがなければ）。URL バーにアドレスを入力するかリンクをクリックすれば、正常に動作する。しかし、JavaScript を使ってドメイン間（または同じドメインの異なるポート間）で POST リクエストを完了することはできない。
私もそう思っていた。
マルッティ・マルミの投稿（2010年6月15日 23:26 UTC）ええ、クロスドメインの JavaScript 呼び出しは禁止されているということを言いたかったのです。つまり、127.0.0.1 上にない JavaScript から 127.0.0.1 を呼び出すことはできません。考えてみると、ブラウザーが悪意のあるクロスドメイン JavaScript に人々の Facebook ページを変更させたら、かなり面白いことになりますね。
JavaScript が 127.0.0.1 へのクロスドメイン POST リクエストを実行することが可能だという報告が入ってきた。他のドメインではなく、特にそのドメインだけだ。素晴らしい……
もしこれが事実であれば、ウェブブラウジングをするシステムで -server スイッチや bitcoind を使用しないでほしい。
パスワードフィールドの追加に取りかかる。
このアイデアについて誰か何かしているのか気になっている。このスレッドとここで説明されている素晴らしい開発に従って、インターネットブラウザー機能の実装の可能性を調査しているところだ。まずこれを試して、Firefox アドオンが発展する中で他の機能と一緒に含めるのが、より簡単な最初の一歩かもしれない（学びながら進めている）。
これが実現する前に、URI がどのような形式を取るかについてコンセンサスが必要だ。URI スキームについて少し調査したが、W3C の承認なしのほとんどのアプローチは好ましくないとされている。W3C が暫定的な URI スキームを承認して保留にするカテゴリーがあるが、保証はない（仮特許のようなもの）。しかし、最も適切なスキームはマグネット URI のようだ。特定のアドレスではなく、コンテンツの一意性から生成されるハッシュによってリソースを見つけるよう設計されている。マグネットはピアツーピアネットワーク上のアプリケーションでの使用を意図しており、アプリケーション固有のデータへの参照用の予約パラメーターがある。基本的に、アプリケーション固有のパラメーターの前に x を付けるだけだ。例：xbitcoin1:?
これはとてもクールに見える！
私は W3C の Tim Berners-Lee と一緒に Web 標準ベースのプロジェクトに取り組んでいる開発チームの一員だ。
bitcoin スキームを登録するというアイデアを、向こうの何人かに持ちかけることはできる……ただ正直に言うと、君たちが必要としているものに対してはオーバーキルかもしれない。
たとえば HTML5 の中で、bitcoin アドレスを RDF(a)でモデル化するのはどうだ。
必要なのは次のどちらかだけだ。1) ごく単純なオントロジー
あるいは OnlineAccount 経由で FOAF と SIOC のオントロジーを使う方法もある。
今朝、W3C の何人かと、FSF と協働している GNU Social / Diaspora の人たち、それからマイクロペイメントの標準化を目指している payswarm の人たちにお知らせを投稿しておいた。
要するに、bitcoin の意味論を HTML で表現するのにマークアップはとても簡単だと思う。
このプロジェクトが大好きだ。みんなで何か形にできるといいな！😊
http://127.0.0.1:[bitcoinwebport]/whatever (http://127.0.0.1:%5Bbitcoinwebport%5D/whatever) を使うのは少し制約が大きい。ユーザーが bitcoin クライアントを持っていて、しかもそれが起動している必要がある。
一方、bitcoin:?whatever を使えば、ブラウザーに URI ハンドラを追加できるので、クライアントが起動していなければ情報を渡して起動し、起動していればウィンドウを開ける。 さらに、ウェブサイトを URI ハンドラとして登録できるようになる。だから、アプリを必要とせず、mybitcoin や他のウォレットサービスを提供するサイトをハンドラとして登録して、リクエストを代理処理させることもできる。このスタイルで標準化することには説得力ある根拠があると思う。