Basic functionality of the Network consists of PUTs and GETs. The launcher is the “gateway to the Network”, not the “interpreter of data”.
Any interpretation of data should be done outside of the gateway. I agree that it isn’t a complicated affair, but I don’t believe that it is required by all Apps that need to use the Network - as is the case with the launcher. In fact, it should hopefully only be useful to a select few!
Security-wise, interpreting data at the same location as the verification of credentials and authorization of application access is, frankly, quite frightening. Despite the developer’s best security practices, this type of design permits way too much contact surface area between the two for my liking.
No, let’s call this what it is - an application that functions as an http proxy server. It is not a basic tool, it is an application. And the way that it connects to the Network is through the launcher, like any other application. And what was the given reason for including this in the launcher?
“Easier for getting started” and “better”. Well, shit - it’s hard to argue with such thought-out logic. But I guess I’ll keep trying.
Computers are really good at automating start-up processes - surprising no one. Using a bit of imagination, I could envision that the control of the proxy on/off be controlled by the addon button inside of the browser.
Not only is this more intuitive, this also functions inside of the browser which the end user will be using anyways. There should be no need to access a running daemon separately in order to turn on and off functionality if the application itself can control this behavior.
The real question here then is: “How much hand-holding does the end user require?”
The answer is a lot.
However, without giving examples, or trying to brainstorm a solution in this non-technical post, I will refer to my earlier point - Computers are really good at automating start-up processes.
The really difficult part here is to get the end user to get everything up and running. Installing software is a much more intense job than installing an addon. The fact is that the launcher (and the rest of the code required to participate in the Network) will have to be downloaded anyways. As far as I’m concerned, any App worth its weight in salt would include the ability to setup the Network’s code - along with its own config - if it is not already.
And that’s not to say that there won’t be bundles that include both the Network’s code as well as multiple applications - browser addon, litestuff, etc. - much like Linux distros do now. But in Linux there is a clear separation between kernel operations and userspace. A separation that translates perfectly to this conversation regarding the launcher and applications.
Once it’s up and running, the expected workflow for controlling an App’s behavior is - seemingly redundantly - to control it from the App itself. In this case, this means through the addon inside of the browser.
Requiring any further knowledge and effort from the end user is not “better” and not “easier to get started”.
to a small degree, by ensuring that all SAFE URLs behave like a normal URL when using a browser that doesn’t understand them! I refer of course to the following suggestion (maybe I should not have split the topics):
for