Sorry for the delay in replying, I missed to follow the forum yesterday.
For sure. I will sum up my findings here.
If the local config file is edited as said in the post, this makes chrome to look out for external applications to handle the URL. Which means that the launcher should register itself for handling the SAFE: scheme. So this forces chrome not to throw an error and pass it to the OS to handle it.
So for discussion, let’s consider that Launcher registers for the SAFE scheme with the OS.
Now, when the user keys in safe:mywebpage.io this will be passed to the registered application for handling the same. Launcher gets the request and fetches data from the SAFENetwork for the URL, how will the response be passed back to the browser?
Other browsers/applications can also start sending requests through the registered handler, making it more uncertain to determine the origin of the request and also to reply back to the request. (Let`s ignore this for now)
Assume that we can pass the data back through an extension/addon which is already installed. We can make use of native messaging API of chrome for exchanging data with launcher and addon. At this point we are not sure on which tab the response message is to be sent. Even if we find a means to send the data to the correct tab, we will be forced to clean the DOM and render the received response (consider it is a plain html for simplicity). The html can have resources linked, such as css and javascript, even these resources can be fetched and injected into the DOM. But places where there are inline definitions for images, we must be able to identify and do the needful to serve. We won’t be able to support relative path referencing.
Moreover, the data (main html) is injected via scripts from the addon. The features like local storage wont work across applications. This happens because the browser doesn’t consider this has a page load and the hostname would be google.com or the previous site from where the safe URL was invoked.
Summing up few ambiguities,
- How will the launcher identify the source of the request (this is just a invocation request)?
- How will the launcher serve the data back to the actual origin?
- How will the resources be handled?
- Can we provide the basic features that normal web does?
A similar problem exists with Safari.
Am not sure what plugin means in this context. If it is NPAPI plugin, then chrome doesn’t support it anymore.
Any suggestions for alternate tlds? I know you are not for the TLD approach 
. But how about we have a fixed hostname, something like http://safenet/mypage.html, http://safenet/blog.mypage.html . This one definitely hampers the readability of the URLs, IMO. @happybeing also had a suggestion of having a real domain, to help in case the users don’t have the setup for SAFENetwork yet.
I have not tried magnet links, but I assume that they also work on the same basis. And I can see that it is not consistent on chrome probably because of various reasons (lack of permission to edit the chrome local state file).
It is good that I finally summed it up, because it would be easier for you guys to help us with your experienced insights.
