Because it hasn't been pulled yet. The thing is, its implemented in all alternative clients afaik, and the results of most previous discussion on URI stuff I've seen before have been mostly "meh, they are close enough, some prefer one some others, but in the end the readability is very similar, if not the same, so its not worth reinventing the wheel".

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...

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?

@ 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?).

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.

@ 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.

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.

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?).

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.

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=[...]

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:

Quote

the following is taken from wikipediaInternet standard STD 66 (also RFC 3986) defines the generic syntax to be used in all URI schemes. Every URI is defined as consisting of four parts, as follows:<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]The scheme name consists of a letter followed by any combination of letters, digits, and the plus ("+"), period ("."), or hyphen ("-") characters; and is terminated by a colon (":").The hierarchical part of the URI is intended to hold identification information hierarchical in nature. Usually this part begins with a double forward slash ("//"), followed by an authority part and an optional path.The authority part holds an optional user information part terminated with "@" (e.g. username:password@), a hostname (i.e. domain name or IP address), and an optional port number preceded by a colon ":".The path part is a sequence of segments (conceptually similar to directories, though not necessarily representing them) separated by a forward slash ("/"). Each segment can contain parameters separated from it using a semicolon (";"), though this is rarely used in practice.The query is an optional part separated with a question mark, which contains additional identification information which is not hierarchical in nature. The query string syntax is not generically defined, but is commonly organized as a sequence of <key>=<value> pairs separated by a semicolon[1][2][3] or separated by an ampersand

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.

Quote

Here is the latest iteration, we could simply emulate http URI, including "userinfo" part

most existing URI handling code will work with this with minimal (if any) changes

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' //<whatever>/<whatever> 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.

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.

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.

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.

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).

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.

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.

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.

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).

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.

Quote

A bigot is a person obstinately or intolerantly devoted to his or her own opinions and prejudices, especially one exhibiting intolerance, and animosity toward those of differing beliefs. The predominant usage in modern English refers to persons hostile to those of differing race, ethnicity, nationality, inter-regional prejudice, gender and sexual orientation, homelessness, various medical disorders particularly behavioral disorders and addictive disorders and religion or spirituality. Forms of bigotry may have a related ideology or world views.

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.

A bigot is a person obstinately or intolerantly devoted to his or her own opinions and prejudices, especially one exhibiting intolerance, and animosity toward those of differing beliefs.

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.

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.

A bigot is a person obstinately or intolerantly devoted to his or her own opinions and prejudices, especially one exhibiting intolerance, and animosity toward those of differing beliefs.

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.

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.

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.

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.

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.

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.

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.

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.)

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).

Ah, I see. Normal people call it "hexadecimal" and I've never heard of "hexadecimal users". Who are these people? Old school programmers, who can't go to the supermarket, because all numbers there are plain decimal?

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.

And why Vladimir's scheme is "too easy" for them? It uses normal decimal numbers as I understand. Should we make it harder for them weird folks somehow?

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.