intrigeri:
> [@u: I'd like to decide on a strategy by February 25, so if we decide
> to go find a very specific kind of mirrors we have time to do this by
> the end of March.]
>
> sajolida wrote (13 Feb 2016 12:49:46 GMT) :
>> The only other issue I see that relates to my work on the assistant, is
>> the fallback solution outside of DAVE so maybe that's off-topic here.
>
> Just a tiny bit :) Retitled this sub-thread accordingly.
>
>> From the blueprint I wonder whether it's really worth writing a version
>> of the JavaScript that works outside of DAVE.
>
> Thanks for raising this topic! I was wondering too.
>
>> You're considering several
>> cases outside of DAVE and BitTorrent:
>
>> A. Release candidates. We're discussing in another thread the
>> possibility of only relying on archive.torproject.org
>> for these. I think we need HTTPS there so your JavaScript
>> outside of DAVE might not be enough to replace this here.
>
> Sounds like a pretty simple matter of programming to me. Our new
> mirror pool design allows us to point to TLS-enabled (HTTPS) mirrors.
> I guess it would be easy to give the JS function a boolean argument
> that specifies whether non-TLS mirrors shall be used, and on calls for
> testing we can use that to pick a mirror among the ones the
> TLS-enabled ones only.
Ok.
> Also note that my secret plan is to leverage this new mirror pool
> design to transition to TLS-enabled downloads only. With Let's Encrypt
> around, plus us allowing mirrors to use whatever virtualhost name they
> want, it looks like this could finally happen :)
Very nice!
>> B. People with no JavaScript, wget, etc. It seems like we need the
>> minimal DNS pool if we want to support these anyway.
>
> Sure, we will need this pool anyway.
>
> But the less we rely on that DNS pool, the better: the less load we
> put on it (i.e. the less users we send to it), the more reliable it
> is, and the less daily maintenance effort is required. This is
> especially true until we have recruited very fast and reliable mirrors
> to put into this pool.
>
> Now, indeed it may be more worth our time to go after such new
> mirrors, than writing code to workaround the lack thereof :)
:) What would this be?
A. Do stats on faster mirror as reported by check-mirrors.
B. Do stats on mirrors with less incidents in the mirrors Git repo.
or you are thinking about recruiting new mirrors we don't yet have in
the pool?
To do this I can dig check-mirrors reports from my trash (1069!) and
compile some stats over the last two years.
I guess that, as time goes by, we will still be able to silently modify
the DNS pool for example to add fast and reliable mirrors from the JS
pool or to remove flaky ones. But we should be able to do this very
rarely compare to the maintenance work we do nowadays.
>> C. Direct download link, as proposed on #11024. These people
>> should anyway be able to do OpenPGP verification on their own so it
>> won't be advertised very prominently and maybe the minimal DNS pool
>> you are proposing for (B) could be reused here. Also, having a
>> constant URL might be nice for these people to bookmark it for
>> example.
>
> Right, and same answer as for B.
>
> Let's add to this:
>
> D. Users of web browsers that DAVE does not support
>
> ... which is similar to B and C the way I see it.
and can't do BitTorrent, yes. These are badly treated as of now :(
> So, all in all: I'm now tempted to invest time into looking for a few
> very reliable and fast mirrors, and put aside the "dynamic mirror URL
> picked with JS outside of DAVE" idea for now. We can always come back
> to it, if the mirrors recruitment is not successful enough: we already
> have code that basically does the job, so it shouldn't be a big deal
> to switch back to this option at the last minute, if required.
>
> Thoughts, opinions?
I'm fine with this.
