Bitcoin Forum
November 11, 2024, 08:25:51 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 »  All
  Print  
Author Topic: URI-scheme for bitcoin  (Read 30878 times)
ec (OP)
Newbie
*
Offline Offline

Activity: 7
Merit: 69


View Profile WWW
February 16, 2010, 08:51:42 PM
Last edit: February 17, 2010, 11:20:26 AM by ec
Merited by Foxpup (4), hugeblack (4), o_e_l_e_o (4), ABCbits (3)
 #1

Hi, intrigued by the bitcoin-system, I have an idea:

The bitcoin addresses could be improved by implementing an URI-scheme like e.g. torrent magnet links.

So instead of 1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, we could more unambiguous say bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, and even configure browsers to redirect clicks on such links to a bitcoin client. This would allow one to implement "donate buttons" on homepages, "pay buttons" on webshops etc.

If an IP should be included, URIs allow this as bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ. If wanted an amount could be specified as bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ (of course for the user to verify in the secure bitcoin-client).

Just my 0.02 ฿ (return them to bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ if you don't like them Wink)
ec (OP)
Newbie
*
Offline Offline

Activity: 7
Merit: 69


View Profile WWW
February 16, 2010, 09:09:40 PM
Merited by OgNasty (50), hugeblack (4)
 #2

An URI-scheme could also be of use for implementing a mobile wallet with QR-codes, so that your buddy who wants to pay you X bitcoins don't have to enter your bitcoin-address manually, but only need to photograph the screen of your mobile phone.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 511


My avatar pic says it all


View Profile
February 24, 2010, 02:37:55 AM
 #3

Yeah, I had totally thought of that too. A magnet link scheme would be awesome. Cheesy
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 7248


View Profile
February 24, 2010, 05:57:43 AM
Merited by OgNasty (50), ABCbits (1)
 #4

That would be nice at point-of-sale.  The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.
The Madhatter
Hero Member
*****
Offline Offline

Activity: 490
Merit: 511


My avatar pic says it all


View Profile
February 24, 2010, 06:39:16 AM
 #5

That would be so awesome... Smiley
Karmicads
Full Member
***
Offline Offline

Activity: 185
Merit: 121



View Profile
May 01, 2010, 06:06:53 AM
Merited by ABCbits (7), Foxpup (6)
 #6

I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per this thread and the wonderful developments described here. It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.

Before this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?

Maybe it is good, not to try implementing a new top level URI scheme, as it is regarded as an ad lib maneuverer, if it is not recognized universally. Adopting the magnet system would avoid this, but in itself magnet is an informal, unregistered scheme. The beauty of magnet is that it can be shared and is open in that sense.

Now, that might all seem very good, because bitcoin is after all a P2P application and it's network does operate on similar principals, but what if the person clicking on the link is not a bitcoin user? What if you want to incorporate some information that is not carried in the existing network, such as the article being sold, shipping information and various other issues. My understanding is that bitcoin only handles the transaction itself, so the user is left to make all other arrangements, contracts and communications independent of bitcoin. Here's where the anonymity is compromised, because here, we are inclined to resort to conventional 'hierarchical  hardwired, or non-anonymous technologies. That's not a criticism of bitcoin by any stretch, because bitcoin is a fantastic way to transact, no question about it. But the transaction is only one side of the coin, if you'll pardon that cheesy pun. Grin

In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. Given that freenet is a user/identity-space intended for information storage, couldn't it also be used as a repository of human readable data files, particular and unique to each user, and incorporating any format of data you wish to use, for embellishing your transaction? Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.

This should keep everything under the same kind of cryptographic P2P infrastructure, and allow infinite diversity of application specific context. I suppose a unique URI hash key, could be borne out of the combination of your freenet+bitcoin hashes and the file encrypted with your freenet key found by decrypting with your bitcoin key, while your bitcoin node can be addressed the other way around. Does that sound right? Of course, if you use your real identity on one, then I guess then, you real identity would be divulged on the other.

Anyhow, I'm sure there's some way to do it. Again, freenet also uses an unregistered URI scheme, but if a variant of magnet is adopted, that will not be a problem. The question remains, if people have hopes of bitcoin becoming a formal recognized currency and a very legitimate deal, then the strict adherence to all other internet protocols might be advisable. I have noted so far nothing in particular that would prevent the registration of a magnet/freenet like URI scheme. I haven't searched them all but one may even exist. Otherwise why not register one?

So the URI scheme needs to be agreed upon as to the classification (i.e. what kind magnet etc, as well do we go legit/formal or not) and format, such as how it is to be laid out:

Components Of A URI

This speaks to the conventions that Mozilla will account for in parsing a URI.

A typical magnet URI, looks like this

magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

A freenet URI is like this:

http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

To be recognized at all, the freenet program needs to be installed and this includes a Java powered web server that recognizes the resource as an item in identity space of the localhost. i.e. my browser sees the whole of freenet as being on my machine. I don't know if this identity space could be addressable without the user having to run a web-server, but I suspect the server is only for the ability to serve web pages as well as recognition of the localhost as the requisite top level domain. The 'http:' indicates that the freenet URI, is nothing special in itself, but the IP address (localhost) certainly is. I suspect a program can address the freenet user space, without incorporating a web server, and the universal links can be made as magnet URIs. As for those who don't have bitcoin installed, I don't know how the URI could be made to have a default fall back, to redirect visitors of that link. to the Sourceforge download for bitcoin. That may need to implemented in code and cookie or environ variable set to record the presence of bitcoin.

Other relevant sites I have visited in the course of this research include:


Any ideas/comments/feedback is/are welcome.  Wink
Steve

D҉ataWraith
Member
**
Offline Offline

Activity: 60
Merit: 10



View Profile
May 01, 2010, 01:40:37 PM
 #7

Before this can happen there needs to be a consensus about what form the URI would take. [snip] ...the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address.
[snip]The beauty of magnet is that it can be shared and is open in that sense.

I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages. Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.). Bitcoin would have to rely on application-specific xBitcoin-parameter(s), and since we probably don't want to mix files with bitcoin transactions in a single link, there's no really compelling reason not to use our own, seperate format, especially since magnet-links aren't officially recognized either.

Quote
In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. [snip] Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.

Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.

However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):

  • address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
  • amount (optional): The amount to send.
  • message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
  • details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
Karmicads
Full Member
***
Offline Offline

Activity: 185
Merit: 121



View Profile
May 02, 2010, 02:15:51 AM
 #8

This just in:...

It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet  Grin <YAY!> Grin

Sorry, I'm not assuming that we must agree on the freenet URI functionality I suggested, just that It is exciting that it can be so readily incorporated, even for experimental purposes. Simply addressing a preconfigured freenet server should do the trick, but perhaps even the existing code can be slightly modified to directly address freenet (without the implicit web server included in the proper freenet install), but by including this FCP code, in the browser add-on, just the addressing and communicating functionality may be incorporated without the overhead of a full blown freenet http server. I assume at this point, the freenet web server, is only needed by the client for browsing freenet, not to service a node. As Bitcoin already addresses a similar P2P network, how hard would it be to make the bitcoin server do freenet inquiries? Could such trickery be included in the JSON intreface?
 
From: http://new-wiki.freenetproject.org/FCPv2

Quote
Purpose

The Freenet Client Protocol is a simple, text-based protocol designed to allow third-party applications to interact with Freenet. Supported functionality includes:

    * Inserting of data into Freenet
    * Retrieval of data from Freenet
    * Querying the status of Freenet
    * Managing the other Freenet nodes that are connected to your own node.


So, it seems you can pull data out of and post data into freenet at will.
Veeeeery interesting indeed.

Aside from that, in the course of looking for proxies or workarounds for freenet URI integration, I believe I solved an unrelated problem to do with my ISP blocking VoIP/SIP (as it's the local telco as well - and yes, I am changing providers very soon). I want VoIP, but my bastard anti-competitive ISP has crippled my modems firmware (which has an inbuilt 2 port analogue telephone adapter), and I hope this work around (Tor) gets past it (I'm not holding my breath) but  Link2VoIP, if you are reading this, I'm looking in your direction.  Wink
Karmicads
Full Member
***
Offline Offline

Activity: 185
Merit: 121



View Profile
May 02, 2010, 07:07:54 AM
Last edit: May 02, 2010, 09:49:16 AM by Karmicads
Merited by Foxpup (4), ABCbits (2)
 #9

Hi DataWraith

Quote
I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages.


I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity. I'm honestly not into superficial popularity if I can help it. The reason to consider a magnet URI IMHO is owing to the Actual stated purpose and draft specifications

Quote
MAGNET is a work-in-progress URI specification, and collection
of standard practices/implementing code to allow a website to
seamlessly integrate with features made available by local
utility programs. In one way, it could be thought of as a
vendor- and project-neutral generalization of the "freenet:"
and "ed2k:" URI-schemes used by the Freenet and EDonkey2000
peer-to-peer networks, respectively.

It's stated purpose is specifically to allow websites to seamlessly integrate with features of local utility programs. It is intended to be vendor neutral and avoid having to reinvent the wheel and avoid further conflicts with other URI schemes. It also follows strong compliance with W3C standards and any scheme using the magnet convention would inherit that rigor.

Quote
NOTES ABOUT THE URI FORMAT:

  - Yes, it looks a little strange to have the "?" right after
    the ":", but by my reading of the relevant URL/URI RFCs,
    that fits the recommended common URI syntax well. (It also
    meshes nicely with the way the parameters are passed on to
    individual local apps.)

  - FYI, EDonkey URIs violate many provisos of RFCs 1738 and
    2396, including the use of "//" at the front of a non-
    hierarchical namespace and the use of illegal/disfavored
    (when not escaped) characters

  - Parameter names and values should officially be www-
    formencoded, just like HTTP web form GET submissions in the
    query-string, though in practice some characters that a
    strict reading of HTML-specs/RFC1738 would suggest should be
    encoded (like '.' and ':') seem not to be encoded.

  - The prefix 'x.' is reserved for application-specific new
    parameter experimentation. Any parameters not beginning 'x.'
    are only to be defined by official MAGNET specifications.

  - Other potential parameters might include a "fallback-
    location" for content that can't be found via P2P, P2P-
    system-specific identifiers (ed2k, sig2dat, freenet), other
    topic qualifiers ("length"), etc. These remain to be
    designed; comments wanted.


Quote
Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).

Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.

Quote

MAGNET URIS, ILLUSTRATED BY EXAMPLE:

(1)

  magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

meaning: show me options pertaining to the "exact topic" (xt)
given by the supplied URI (specifically, an URN)

(2)

  magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3

meaning: show me options about this exact topic, but use
the included (unverified) "display name" for user convenience

(3)

  magnet:?kt=martin+luther+king+mp3

meaning: show me options about the "keyword topic" (kt)
given by the string

(4)

  magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7

meaning: show me options about the two exact topics given

(5)

  magnet:?mt=http://weblog.foo/all-my-favorites.rss

meaning: show me the options for the "manifest topic" (mt)
fetchable via the given URI. This could also be an URN.
Manifest topics include lists of other items.



Quote
Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.

Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it. I would be more concerned with robustness and not being painted into a corner myself. The effort to implement backward compatibility and forward extensibility, having been considered from the outset, is a small price IMHO. In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed. Also the URI should of course include this freenet functionality, as an optional parameter. So if not specified, the information to do the basic transaction would still be legitimate. It would not then be compulsory to use in publishing the URI, but the handler should still be able to take the parameter if it is used, otherwise the optional choice you are proposing is between two different incompatible URI schemes. Measure twice, cut once.

Quote
However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):

    * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
    * amount (optional): The amount to send.
    * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
    * details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.

The amount: Yup goes without saying.

Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. The need to reference a supplementary document begins here. The payer can send their message in the software interface (either the standalone program or the Firefox add-on), The link, at a minimum, identifies the recipient and the amount, that must be passed to the software. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link? What message needs to be passed by the payer, that is not possible in the interface, but is possible by clicking on the link? That would imply that the link invokes methods like post or get, that are exclusively http/s functionality, that is defeating the purpose of having a purpose made URI scheme. Post and Get functions need to be addressed within the hierarchical namespace of TCP/IP and/or physical file path names.

Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.

As far as this "you could also link to freenet, i2p and tor to keep things anonymous." is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with. That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless. If I can make the URI handler address the freenet namespace, then I suggest it would much better to store the files there in the first place. Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.

If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.


EDIT:

Re my comment "The amount: Yup goes without saying." I take that back. I was thinking in terms of links only as instigators of payment events, but of course, if the amount and other parameters are left blank, it should then default to acting as an identifier link to instigate a payment at the behest of the payer. A simple donate button would only need one parameter and zero redirections/login/confirmation/calculate and change currency before you can finally send, to not see your transaction eating the dust of snailmail on horseback, in the event that you don't have a credit card. (Suck on that that PlayPal). That, along with the naming alias idea suggested by DataWraith AKA (having an address), if that;s what you meant DataWraith, is certainly worth implementing for my bitcoin.  Wink
D҉ataWraith
Member
**
Offline Offline

Activity: 60
Merit: 10



View Profile
May 02, 2010, 11:13:09 AM
Last edit: May 02, 2010, 11:33:08 AM by DataWraith
 #10

Karmicaids, thanks for taking the time for such a detailed reply.

It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet  Grin <YAY!> Grin

Oh, I thought you meant that when you spoke of using freenet. The user runs freenet and Bitcoin would communicate with it using its control protocol. However, running Freenet requires considerable computer resources, especially bandwidth, and personally, I do not want to run a freenet node for that reason alone. That's why I wanted this to be optional.

Quote
I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity.

I had the impression that you did not want to re-invent the wheel, and that's why popularity played a part -- that the existing acceptance of magnet links in other software was a plus.

Quote
Quote
Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).

Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.

Okay, sorry, seems I haven't made entirely clear what I mean here. I'm aware of how magnet links refer to content, rather than a location in a hierachical namespace.

Perhaps it's just a difference of mental models: For me, a bitcoin transaction is, for lack of better words, not a thing so much as a process. In my mind, magnet links refer to things (usually a file -- whether by content hash or by location), and trying to use them to refer to a process strikes me as a little awkward. Magnet links identify things you then have to go fetch, while a bitcoin transaction is completely described by the link itself (although you still have to say "Yes, send the coins." once you click the link).

To me it seems that using magnet links would be to (ab)use them for something they were not meant to describe, as they orignated as a replacement for ed2k://, freenet://, et al., describing how to get a file.

A bitcoin-link should be more like mailto: than magnet: IMHO.

Quote
Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it.

Yeah, my mistake, sorry.

Quote
In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed.

IIRC the web server is pretty much integrated into Freenet itself. You can use the simpler FCP protocol to talk to a Freenet instance, but because of the type of content on Freenet, not many people are willing to host a publicly accessible instance, so you would have to run your own. I don't begrudge that you want to be able to do this, I'm just not willing to do it myself. I'd much rather host a TOR hidden service -- that's why I suggested to use a general, full-featured URL as the details parameter, instead of making it freenet specific.

Quote
Quote
    * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.
    * amount (optional): The amount to send.
    * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)
    * details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.

Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.

Well, yeah, I meant the bitcoin signature. I called it address, because that's what it says in the bitcoin client (i.e. "Change your address"). I indeed thought that one should use different aliases, just like the exchange sites currently do: You get an address (or signature, or whatever) to send coins to, and because that address was only given to you, the recipient knows the payment is from you.

A system to translate aliases would of course be nice, but I think that's better handled with an address book or mybitcoin.com or something.

Quote
Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link?

Yes, exactly! The text for the sending party can use the normal route. But what if I want to pre-specify the text that should be sent?

This has an analogue in mailto:-links: If you want someone to send you an email, you can also specify a subject he/she should use: mailto:alice@example.org?subject=Test. So if I am selling something on, say, ebay, I can give the buyer a bitcoin link that includes the message "Payment for Ebay auction #12345", so he/she does not have to enter it themselves, possibly making a mistake if the code is more cryptic than #12345.

Quote
Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.

Sorry, I mistakenly tend to use the terms URI, URL, etc. interchangeably because you enter it into the address bar %). Again, sorry if this lead to confusion.

What I wanted here was to make this additional information general. Some examples might clarify this:


The creator of the link chooses where to put the additional details, and the recipient decides whether he needs the supplemental information badly enough to install Freenet/Tor/I2P. That's one of the reasons for including a short message in the link itself: the additional information should not be critical to the transaction.

Quote
As far as this "you could also link to freenet, i2p and tor to keep things anonymous." is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with.

But wouldn't that make the use of Freenet mandatory? I would like this to stay more flexible.

Also, if I were to run an online shop, I'd rather have people look the details up on my own website rather than them having to install freenet. That might also link my shop's reputation with Freenet, which given Freenet's reputation, might be undesirable.

Quote
That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless.

Yup. That's another reason for wanting to also allow normal HTTP(S) URLs. If I have not misunderstood, you seem to want to make the use of Freenet for transactions mandatory, which is something I strongly disagree with.

Quote
Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.

Not every single transaction needs bulletproof anonymity. Think Open Source projects receiving donations, or online shops. If you (a) need more details than the short message parameter provides, and (b) you want to be totally anonymous, you can just specify a freenet or Tor or I2P-URL (or URN? -- this is confusing :-/ ). If you don't need the added anonymity, you don't have to make the effort to run Freenet/Tor/I2P/whatever.

Quote
If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.

Well, we're all together in this. I just hope to arrive at the best possible system. :-)

Thank you for your thorough explanation, and patience with my suggestions.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 7248


View Profile
May 16, 2010, 10:37:21 PM
Last edit: May 16, 2010, 11:53:05 PM by satoshi
 #11


There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer.


A bitcoin-link should be more like mailto: than magnet: IMHO.

I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page.  Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in.  It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog.  You'd still have to press Send.  We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.


lachesis
Full Member
***
Offline Offline

Activity: 210
Merit: 105


View Profile
June 11, 2010, 02:51:56 PM
 #12

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>
That's a very pragmatic answer. I like it.

However, how would that work with the combined IP / Bitcoin Address URI (URN? URL?) scheme described here?
[link]http://bitcointalk.org/index.php?topic=158.msg1322#msg1322[/link]

I know it's been nearly a month, sorry.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 7248


View Profile
June 16, 2010, 12:15:47 AM
Last edit: June 16, 2010, 12:33:56 AM by satoshi
 #13

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00

But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address.  With a bitcoin address, the user can't send an unidentified payment.  They can't send payment until they've been given a correct bitcoin address to send to.

What would be nice about sending by domain is you could visually verify who it's going to.


A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589

and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
lachesis
Full Member
***
Offline Offline

Activity: 210
Merit: 105


View Profile
June 16, 2010, 06:14:05 AM
 #14

But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address.  With a bitcoin address, the user can't send an unidentified payment.  They can't send payment until they've been given a correct bitcoin address to send to.

What would be nice about sending by domain is you could visually verify who it's going to.
I think that hiding the complexity of Bitcoin addresses from the casual user is a good thing. Barring that, it should be possible to embed an observable but unalterable message with address transactions. Is there some reason this is technically infeasible?

A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589

and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).

Try clicking this link:
http://127.0.0.1/
You probably don't see anything (unless you're running a web server on your system), but the browser happily tries to take you there.

XMLHTTPRequest is what we were discussing in that other thread.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
sirius
Bitcoiner
Sr. Member
****
Offline Offline

Activity: 429
Merit: 1002



View Profile
June 16, 2010, 08:26:14 AM
 #15

Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.

Iris — for better social networks
I'm not a forum admin - please contact theymos instead.
bencoder
Member
**
Offline Offline

Activity: 90
Merit: 10


View Profile
June 16, 2010, 12:59:40 PM
 #16

Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.

You could do an iframe that pointed to something like http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> and then that iframe would contain a little bitcoin interface stating how much & who you're paying and a button to confirm or cancel the payment. If you confirm the payment then it sends the coins to the domain and then redirects to the return value in the query string. bitcoin could add a ?paid=true or ?paid=false to the return location as well so the return script on the domain could then check if it received the payment correctly, or cancel the order.

Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
lachesis
Full Member
***
Offline Offline

Activity: 210
Merit: 105


View Profile
June 16, 2010, 07:38:32 PM
 #17

Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
That's not exactly true. At the moment, Bitcoin only binds RPC to the loopback interface, 127.0.0.1. I would assume that this web interface would be the same. However, there SHOULD be a password to prevent trojans from trivially sending your wallet away. Wallet encryption needs to happen, too.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 7248


View Profile
July 18, 2010, 04:06:16 PM
 #18

I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
That's what I thought too.

Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1.  Not other domains, but just specifically to that one.  Great...

If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.

I'll get started on adding the password field.
melvster
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250


View Profile
July 21, 2010, 12:47:06 PM
 #19

I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per this thread and the wonderful developments described here. It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.

Before this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?


This looks very cool!

I'm part of the dev team that works with Tim Berners-Lee of the W3C on web standard based projects.

I can run the idea of a bitcoin scheme being registered by some of the folks there ... but to be honest it may be overkill for what you need.

Why not use RDF(a) to model a bitcoin address in, for example, HTML5.

You just need either 1) a very simple ontology

<meta property="bitcoin:address" content="u34827uirhe243" />

Or use the FOAF and SOIC ontologies via OnlineAccount.

I've posted some notices to some of the W3C folks this morning, as well as the GNU Social / Diaspora working with the FSF, and the payswarm folks that are looking to standardize micorpayments.

Bottom line, I think the markup is very easy to capture the semantics of bitcoin in HTML.  

Love the project, hope we can all work something out! Smiley
darkskiez
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
July 21, 2010, 12:47:59 PM
 #20


Using http://127.0.0.1:[bitcoinwebport]/whatever is a bit limiting, it requires that the user has the bitcoin client, and that the client is running.

Using bitcoin:?whatever however allows us to add a uri handler to the browser, so it launches the client with the information if it is not running, or opens a window if it is running.
In addition it allows websites to be registered as URI handlers, so people could register mybitcoin or other wallet service providing website to handle the request for them, without requiring the application. I find this a compelling argument to standardise on this style.


Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!