If your intention is to spur mass adoption @happybeing, then I do believe that you are thinking along the right lines. While I do not share the “What About the Validity of the Addon” argument point of view, I do have several other points to make.
Use technical ignorance advantageously
When an individual navigates to a link to a specific page on the network, yet is unaware of the way that the Network works, this will serve as a teachable moment, and inform them of primarily how to access the content that they are expecting, and secondly what they are using (if they choose to explore further).
Create a human-meaningful link between the clearnet and the Network
While some may argue that the break between the clearnet and the Network be clean, I would respond that if that were the case, we shouldn’t be allowing browsers to access the Network in the first place.
There is a reason to do so, and that is because the usage thereof is widespread. Widespread and familiar. And for mass adoption, either intuitiveness or familiarity is tantamount. Familiarity is then indeed a boon for mass adoption, despite it’s ability to obscure the clean break.
Provide end-users with informative error messages
If a user navigates to a location on the Network, but gets redirected to the server, then they can be sure that the addon is not working properly.
Of course, the addon must provide a distinct “power”-type button (think uBlock origin) that turns this on and off, or else we’ll get many a “help wanted” post that ends with the actual activation of the addon.[1]
Breaks historical usage
The custom URL scheme (safe://
) approach would have been ideal as it would correlate to a number of other applicable instances, such as file://
, magnet://
, ftp://
, (even bitcoin://
!!!) etc. It’s almost as if these custom schemes were made for just such a purpose.
This type of behavior handling has been working for ages even before browsers were invented, so I am frustrated that the addon developers so easily gave up on this idea.
Applications like the Windows Store (and others) appear to get around this by adding themselves to the “Local State”. There are work around (very hacky ones), but adding these are kind of convoluted when Chrome should have native support.
– austin.a@mavenwave.com - Chromium Support Issue 162124: Chrome can’t handle custom URI schemes in Windows 8
or
Redirects to a standardized URL
ICANN does not care about the Network. If anything, they would be vehemently opposed to it. If they restrained themselves to only acting inside of their juristiction (ha!) and they follow their own rules when it comes to domain name administration (HA!) then they have no reason to standarize this URL to our own usage.
The fact of the matter is that URLs change their pointers and change hosts and change owners. Any URL registration is subject to human error and oversight (if nothing more malicious), and may not remain what we wish it to remain.
This is a side-effect of our disastrous DNS system, and despite our best intentions is subject to redirection; for instance if the registration mistakenly expired, or a non-authoritative DNS server’s cache had not been updated.
Server administration
I believe that the concerns about the server have been aptly detailed out previously in this thread.
EDIT: Despite my concerns, and after re-reading this thread, I do believe that this is a very ingenuitive course of action and would throw my support behind it if implemented.
[1] I am firmly of the belief that users should not be able to access clearnet sites while using the network for security reasons in the same browsing session. Therefore I support the idea that the addon is able to be turned on and off.