The registerProtocolHandler method specifies a whitelist of schemes for which web applications are allowed to register themselves as possible handlers ( https://html.spec.whatwg.org/#whitelisted-scheme ). On the JQuery Standards repository there is an issue stating that “A blacklist (not a whitelist) should define whether URL schemes are available for registration” ( https://github.com/jquery/standards/issues/12 ). I would like to support it with a concrete example.
One of the whitelisted schemes is “bitcoin”, which allows sending money to a Bitcoin address. The problem is that Bitcoin is not the only one cryptocurrency. “Crypto-Currency Market Capitalizations” site lists currently 527 different currencies ( http://coinmarketcap.com/currencies/views/all/ ). Some of them are very similar to Bitcoin (like Litecoin), some are similar but use a different mechanism for securing the blockchain (like Peercoin and Blackcoin) and some are based on a different codebase (like NXT and Monero). However only Bitcoin clients are able to use registerProtocolHandler. Web wallet Coinkite already tries to bypass that limitation by generating QR codes and URIs using “bitcoin” scheme for each currency they support. They also claimed that the world should use one URI scheme for all cryptocurrencies ( https://twitter.com/coinkite/status/470898769446584320 ). What may work for their case, not necessarily is a proper general solution. People may want to use different clients for different coins and, for example, canonical Bitcoin client shouldn’t need to know anything about alternative currencies. I see two simple solutions to this problem: ⒈ Deprecating the “bitcoin” scheme and creating a “coin+xxx” scheme family, which, analogously to “web+xxx”, will be whitelisted. ⒉ Dropping the whitelist solution in favor of a blacklist of URI schemes which are forbidden to be registered. Besides backwards compatibility, this solution has other advantages: ⓐ It is more flexible and can support not only cryptocurrencies, but many other emerging technologies, allowing developers to create them without the need to gain a specific permission. The whitelist looks like an overregulation which inhibits innovation. ⓑ It is more adjusted to the nature of the problem. Existing whitelisted schemes are often about message sending (“email”, “mailto”, “sms”), while cryptocurrency schemes are about money sending, so it looks that they belong to the same level of abstraction. Furthermore, some of the cryptocurrencies allow also message sending. What are your thoughts about that? Are there any security considerations preventing the whitelist solution? Or maybe a more general one should be worked out?