j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM13<div class="post">Hi DataWraith<br/><br/><div class="quoteheader">Quote</div><div class="quote">I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages.</div><br/><br/>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 <a href="http://magnet-uri.sourceforge.net/magnet-draft-overview.txt">Actual stated purpose and draft specifications</a><br/><br/><div class="quoteheader">Quote</div><div class="quote">MAGNET is a work-in-progress URI specification, and collection<br/>of standard practices/implementing code to allow a website to<br/>seamlessly integrate with features made available by local<br/>utility programs. In one way, it could be thought of as a<br/>vendor- and project-neutral generalization of the "freenet:"<br/>and "ed2k:" URI-schemes used by the Freenet and EDonkey2000<br/>peer-to-peer networks, respectively.<br/></div><br/>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. <br/><br/><div class="quoteheader">Quote</div><div class="quote">NOTES ABOUT THE URI FORMAT:<br/><br/> - Yes, it looks a little strange to have the "?" right after<br/> the ":", but by my reading of the relevant URL/URI RFCs,<br/> that fits the recommended common URI syntax well. (It also<br/> meshes nicely with the way the parameters are passed on to<br/> individual local apps.)<br/><br/> - FYI, EDonkey URIs violate many provisos of RFCs 1738 and<br/> 2396, including the use of "//" at the front of a non-<br/> hierarchical namespace and the use of illegal/disfavored<br/> (when not escaped) characters<br/><br/> - Parameter names and values should officially be www-<br/> formencoded, just like HTTP web form GET submissions in the<br/> query-string, though in practice some characters that a<br/> strict reading of HTML-specs/RFC1738 would suggest should be<br/> encoded (like '.' and ':') seem not to be encoded.<br/><br/> - The prefix 'x.' is reserved for application-specific new<br/> parameter experimentation. Any parameters not beginning 'x.'<br/> are only to be defined by official MAGNET specifications.<br/><br/> - Other potential parameters might include a "fallback-<br/> location" for content that can't be found via P2P, P2P-<br/> system-specific identifiers (ed2k, sig2dat, freenet), other<br/> topic qualifiers ("length"), etc. These remain to be<br/> designed; comments wanted.<br/></div><br/><br/><div class="quoteheader">Quote</div><div class="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.).</div><br/>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. <br/><br/><div class="quoteheader">Quote</div><div class="quote"><br/>MAGNET URIS, ILLUSTRATED BY EXAMPLE:<br/><br/>(1)<br/><br/> magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C<br/><br/>meaning: show me options pertaining to the "exact topic" (xt)<br/>given by the supplied URI (specifically, an URN)<br/><br/>(2)<br/><br/> magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3<br/><br/>meaning: show me options about this exact topic, but use<br/>the included (unverified) "display name" for user convenience<br/><br/>(3)<br/><br/> magnet:?kt=martin+luther+king+mp3<br/><br/>meaning: show me options about the "keyword topic" (kt)<br/>given by the string<br/><br/>(4)<br/><br/> magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7<br/><br/>meaning: show me options about the two exact topics given<br/><br/>(5)<br/><br/> magnet:?mt=http://weblog.foo/all-my-favorites.rss<br/><br/>meaning: show me the options for the "manifest topic" (mt)<br/>fetchable via the given URI. This could also be an URN.<br/>Manifest topics include lists of other items.<br/><br/></div><br/><br/><div class="quoteheader">Quote</div><div class="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.</div><br/>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.<br/><br/><div class="quoteheader">Quote</div><div class="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):<br/><br/> * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.<br/> * amount (optional): The amount to send.<br/> * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)<br/> * 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.<br/></div><br/>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.<br/><br/>The amount: Yup goes without saying.<br/><br/>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. <br/><br/>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. <br/><br/>As far as this <b><i>"you could also link to freenet, i2p and tor to keep things anonymous."</i></b> 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.<br/><br/>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.<br/><br/><hr/><span style="color: maroon;"><b>EDIT:</b></span> <br/><br/>Re my comment <span style="font-family: Verdana;"><i>"The amount: Yup goes without saying."</i></span> 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. <img alt="Wink" border="0" src="/static/img/emoticons/wink.gif"/><br/></div> text/html
https://whatsonchain.com/tx/a7d058ab2f7fcabfa1cb1fdec2d3406ef3a9e0120e4ec5fc3865e597a8aba58c