Topic: [ANN] Bitcoin URL handler (Read 8611 times)

theymos wanted someone to test it before applying it.

Hexadecimal is a newer, incomplete number system. Probably everyone who knows Tonal can use Decimal, but prefers Tonal because it is a sensible number system and thus easier to work with.
Some people object to the standard URIs because it is "too easy" for tonal users. I agree that people shouldn't go out of their way to make things harder for "weird folks". But there has been no other argument made against the standard URIs as of yet.

I actually do not give a shit, the slower adoption of bitcoins goes the more time I have to mine a boatload of bitcoins until multinationals take this over.

defxor, there was no hostility from me towards anyone (at least until I am forced into defensive position). All that was proposed is to implement an alternative URI scheme not instead of but as and addition, and alternative. Than this got attacked by tonal zealots because we have no idea what's that tonal shit is. 

I do not care. If you do not want to see wisdom in making things simple and intuitive for most lay people, I am not going to push it down anyone's throat, give it decade or two and they will see on their own (or not).

It means not writing software according to the same mindset that gave you the Internet, World Wide Web, email and a host of other cool things I'm quite sure you use every day.

I fail to understand your hostility towards best practices.

http: serves files, bitcoin: wouldn't.

Quoting from a comment by Fredrik on a relevant thread at Falkvinge's blog:

The double slashes are to tell that a file is located on a remote computer. When not specifying a file they make no sense. Bitcoin addresses don’t specify where something is.

Local file, option 1:
/etc/passwd
file:/etc/passwd

Remote file:
//example.com/etc/passwd
http://ftp://example.com/etc/passwd
http://example.com/etc/passwd
https://example.com/etc/passwd

Local file, option 2, with empty host name:
///etc/passwd
file:///etc/passwd

It’s good to have something like the “mailto:” URI scheme because it’s simple, and it supports adding a subject line that users will like to log in their accounting. (One click transactions are not one click if you need to type a description for the transaction manually.)


(Falkvinge's own suggestion was bitcoin:amount/address)

People who prefer the Tonal number system rather than Decimal/SI.

That it's "too easy for tonal users" is the only "argument" that's been put forward against the current spec. If you're trying to argue on some other premise, maybe you should state it instead of simply promoting an older pre-standard draft without giving any reasons.

Just preserving the above to demonstrate that all this argument was actually about this tonal thing (whatever it is) or absence of it after all. This does make things very clear. You have just invalidated everything you said against alternative URI scheme and demonstrated that the only reason you attack it is that it does not includes your "tonal". Talk about intolerance and tolerance and religious blindness after that.

I actually did not even had a single thought about tonal until this point maybe except a joke I made sometime earlier which suddenly turned to be more relevant that I ever thought it would be.

Could not care less if this tonal 'tihng' is used or not. I do not know what it is and do not want to know. People here including me have been tolerating this tonal nonsense for long time by simply ignoring it and I will continue to do so. But must I say this religious conversion crusade of yours is indeed annoying.

I have got no more time to waste on further discussions with religious fanatics.

Um, no. Why don't you read the definition you posted? The only objection to the bitcoin: URI spec has been that it's supposedly too easy for tonal users. There is nothing in it to force or even encourage people to use tonal. I don't mind if people use decimal (though I do consider it a dumb decision), only when people try to force me to use it as well, which is the case here.

We are going to have to agree to disagree on everything you said in your last post quoted above.

Moreover, it seems that anyone who disagrees with you is a bigot now.


If anyone demonstrates bigotry here it is you, Luke-Jr. The above definition exactly describes you behaviour and position, not only ITT but in many other discussions as well.  If there was an ignore function on this forum I would use it on you right now. Goodbye.

How can you not see how this is non-compliant? Amounts are not usernames; "payees" (whatever those are) are not passwords. Neither addresses nor messages are in any way hierarchial. It also does not make any improvement on the existing URI scheme. Not to mention it isn't backward compatible.
The current standard is basically ideal for payments. The only "arguments" that have come up (all fairly recent) are based on bigotry and (to a limited extent) the flawed assumption that everyone will always want to use BTC for pricing (proven recently by many efforts to come up with a new common unit, which the bitcoin: URI scheme spec handles gracefully).

Thank you for your fair comments. It seems that there is some misunderstanding, perhaps due to poor communication from btc: (let's call it so, for now) URI scheme advocates.

I'll quote this from the bitcoin wiki URI page:


The latest modification of btc: scheme, which takes into consideration the fair critique.

This is what I consider the latest and the best and the most compliant btc: URI scheme proposal.


Now, for the life of me, I fail to see how is this non compliant with relevant RFC. You would have to claim that commonly used http: URI's are non compliant as well to support 'non compliance' argument.

There is claim that to be 'compliant' /// must be somehow hierarchical, but well, we do have bitcoin address as the root of hierarchy, and different messages as sub trees. Nothing wrong here at all.

Now please, do tell me how is this not compliant? Anyone? I must be an old dinosaur who forgot all this stuff ages ago, but I really do not see how this is not 'compliant' and even if it is, little bending of the rules is not such a bad thing, do not bee too dogmatic here and maybe even less nitpicky.

Here is a fledging developer who thinks that existent URI scheme is crap (so do I) and whether he is right or wrong lets encourage his effort to implement an alternative.

This is true in case that there will only be 2 Parameters. In the moment when the number of Parameters will increase the Version one is much better bcs. you can add as many (future) parameters as you like. Think about it. Example:
bitcoin:1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L?amount=0.45&msg=Thanks for your work!&xyz=[...]

There was a consensus reached at the time, and implementation proceeded to take place over the few months following. It is now supported by most Bitcoin-related software where it makes sense, and has been for some months at least.

Your proposal was, in reality, an early pre-draft version of what became the standard on the "URI Scheme" wiki page. After the community revised it to comply with the generic URI standards, that wiki page was the end result. X-btc aims to specify a URI scheme that is applicable for more than just payments (which is all the bitcoin: URI scheme covers presently). It also has (had?) some generic-URI-format compliance issues that might be good to work out.

@ Luke-Jr, There never was consensus reached on that. It is not a standard, just a page on wiki. Please do not call, whatever you like, a standard, it is not. If I am wrong here please explain why.

@AlexZ. Please calm down. Insulting fellow community members does not help anyone. I would humbly suggest you to consider removing insulting remarks and hopefully apologize to 'error' either privately or publicly to get this little accident behind us.

@Error, I apologise for somewhat uncivil behaviour of AlexZ, please consider if you we can get this behind us, and if you have any suggestions, how we could modify btc: URI scheme to make it 'compliant' (whatever this means) please do tell us. I also would happy to discuss this privately, if appropriate.

Now. Back in January the consensus (IMO) was that whoever does actual implementation is in position to select which URI scheme to chose. This seems to be a very wise approach (thanks Gavin), which has potential to stimulate software development instead of facilitating URI religion wars and endless flames.

I have one practical suggestion. Lets have more than one URI scheme.

We have a well documented bitcoin: scheme RFC on wiki, great!. Let's prepare competing btc: scheme suggestion along the lines of what myself and AlexZ are advocating, let's also have bit-x: scheme (why not?).

Than whoever advocates or likes whichever scheme is free to document it, implement it, submit pull requests in competitive manner.

Best of all, we do not have to implement only one scheme. let's have all of them available, though, in different namespaces. Let market forces, webmasters, merchants, and users select and use whichever scheme appeals to them most. This IMO is very libertarian, capitalistic and fair approach, very much in spirit of bitcoin.

Frankly, I am confident that if all bitcoin: bit-x: and btc: schemes are implemented and supported than bitc: will be preferred by most people. But I may be wrong. Let's keep open mind and let's allow all schemes to be supported equally and without undue prejudice and discrimination (please, "error").

Thank You.

P.S. hey bc: namespace is up for grabs, got a better idea for URI, document it, implement it. The more, the merrier.

Or compare to the standard that the community came up with back in January: https://en.bitcoin.it/wiki/URI_Scheme

The hierarchical part of an URI should be, well, hierarchical. The transaction amount is not part of any hierarchy and should therefor should be placed in the query part of the URL.

Compare with the existing schemes: https://secure.wikimedia.org/wikipedia/en/wiki/URI_scheme#Official_IANA-registered_schemes

>Why all the people on the forum write addresses as plain text and not as clickable links that will open a payment window?
Report to moderator  
>bitcoin://16rpY3LAf7kQFHzmMtB71eXTTTDLG5AWy3/  (Bitcoin URI handler is here

exactly - if you are on a device and have a bitcoint client --- this works. if someone is on a device that doesnt have a client - it doesnt work. either way, these should be clickable links so they can facilitate the mainstream usability of bitcoins.

>Introducing some privately owned domain into decentralised currency URI scheme, whether standard or not, does not look very appealing. Nice try with a community infiltration attack though...

http://blockexplorer.com/address/15NpyCrWkTMzTYRTuUrQhB4K2MUspPjeTi

who owns blockexplorer.com? people link to it all the time --- i tried to contact them but there's no contact on the site, and their whois information is obfuscated.

so how is this:
http://coin.is/15NpyCrWkTMzTYRTuUrQhB4K2MUspPjeTi much different?

seriously i dont know and thats why im asking. who would need to own "coin.is" to make it not an infiltrating attack on the community? a non profit organization? a publicly traded corporation? a trust in the name of --- all coin hashes? i'm all ears and up for making bitcoin usable by everyone on earth, by whatever means necessary. help?

I said it before: Vladimir's thing is not a compliant URI.

Can we try to keep things civil, I mean seriously, who does that help?  Talk with him about it, calmly instead of posting on other threads that some guy is an idiot.