Haketilo

I think it would be a great idea, especially given the mirror suggestion you provide (it wouldn't be too hard to enable mirrors over HTTPS in any case).

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla. Aren't scripts served by Hydrilla downloaded using the text key?

it wouldn't be too hard to enable mirrors over HTTPS in any case

Depends for whom. Developing this should be easy, but if a user decides to set up a mirror on localhost, at least a self-signed cert would need to be created and imported into the browser. This can probably be automated when using a package manager, though (sorry, Losedows useds).

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla.

I silently assumed browser's own caching mechanisms would result in more re-downloads than if a proper Hydrilla-aware caching of scripts was in place. I might be wrong :)

it wouldn't be too hard to enable mirrors over HTTPS in any case
Depends for whom. Developing this should be easy, but if a user decides to set up a mirror on localhost, at least a self-signed cert would need to be created and imported into the browser. This can probably be automated when using a package manager, though (sorry, Losedows useds).

Somehow that fact managed to slip my mind despite the fact that I've been thinking about certificates quite regularly in the past few days (as part of a potential testing system).

In any case, if Microsoft ships the tools to generate self-signed certs, I expect that would make enabling HTTPS reasonably doable. Would there be any significant group of people who want to set up a local proxy yet couldn't (with some searching) determine how to deal with the certificates, regardless of OS?

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla.
I silently assumed browser's own caching mechanisms would result in more re-downloads than if a proper Hydrilla-aware caching of scripts was in place. I might be wrong :)

You're definitely right about that! The point of confusion, which I now realize I never actually stated, was to do with it affecting Hydrilla; aren't scripts served by Hydrilla copied locally anyway, leaving only scripts from external sources specified by hash and url?

In any case, if Microsoft ships the tools to generate self-signed certs, I expect that would make enabling HTTPS reasonably doable.

We don't need M$' tools for this. I've been able to use Wine and MinGW to develop Windows programs in the past using only libre software. And even linked with OpenSSL ^{^}
I am also looking forward to be able to do the same for Crapple macOS using Darling.

Would there be any significant group of people who want to set up a local proxy yet couldn't (with some searching) determine how to deal with the certificates, regardless of OS?

If we want to make it a viable solution to the issues mentioned, we need to make the biggest possible subset of our users want to set it up.
Most computer users and even many IT students are completely unaware of what certificates are. While learning about it is possible, it is not possible in a short time (~3 mins a user expects to spend installing stuff). If this is to be a viable solution, we need to automate everything. Also, if we don't, we might look unprofessional :/

That said, I'm somewhat confused as to how this would/could put burden on Hydrilla.
I silently assumed browser's own caching mechanisms would result in more re-downloads than if a proper Hydrilla-aware caching of scripts was in place. I might be wrong :)

You're definitely right about that! The point of confusion, which I now realize I never actually stated, was to do with it affecting Hydrilla; aren't scripts served by Hydrilla copied locally anyway, leaving only scripts from external sources specified by hash and url?

No. The way I wrote Hydrilla it assumes (unlike Hachette) that the scripts are (1) never referenced from external sources (except approved mirrors) and yet are (2) always served by hash and url. Why so? (1) because we don't want to rely on third-party servers but rather server the same thing ourselves and (2) because this is more flexible. We'll add a "pull source" button in the settings which will enable the user to get a copy anyway. And once we come to serve various versions of the same script (minified, non-minified, map) we won't be wasting bandwidth by sending the source together with the actual settings. Plus it was simply easier for me to program this way because I could leave the work of serving script files to Apache :p

I actually assumed Hydrilla would only inform the clients about a path to script resource (e.g. "somedir/somefile.js") and that path would then work when appended to any of the mirrors of that repository (e.g. "https://hydrilla-repo1.org/content/somedir/somefile.js" and "https://hydrilla-repo-service.org/mirror-of-koszko_org/content/somedir/somefile.js". We could then even separate the API server from actual mirrors ^{^}

No. The way I wrote Hydrilla it assumes [...]

That makes sense! All your other points follow then, I think, except that most computer users and IT students have no idea what certificates are- which unfortunately I don't disagree with you about :/.

Plus it was simply easier for me to program this way because I could leave the work of serving script files to Apache :p

LOL- don't change that!