Subject: Re: [bug#52555] [RFC PATCH v2 5/5] substitute: Fetch substitutes using ERIS.

From: pukkamustard <[email-masked]>
Date: Wed, 02 Feb 2022 10:38:55 +0000

Maxime Devos <[email-masked]> writes:

> [[PGP Signed Part:Undecided]]
> pukkamustard schreef op di 25-01-2022 om 19:22 [+0000]:
>> +  (define* (best-uri narinfo #:key (eris? #f))
>> +    (if (and eris? (narinfo-eris-urn narinfo))
>> +        (values (narinfo-eris-urn narinfo) "zstd" #f)
>> +        (narinfo-best-uri narinfo #:fast-decompression?
>> +                          %prefer-fast-decompression?)))
>
> Why is ERIS the best here?  Fast download speeds, decentralisation,
> less network I/O, less heat production, more pronouncable than HTTPS?
> I would add a comment here.

Those are all possible reasons. I think we first need to do some
experiments to see if any of those claims can be justified.

In general, the logic for when to use ERIS transports needs more
thought.

For one, I think it should be user configurable. I can imagine that
certain users do not want to use decentralized substitutes at all. Users
should be able to deactivate the entire ERIS thing.

For the default, I personally think it would be ok to try and use
ERIS. The only thing we absolutely need is a clean fallback logic that
transparently falls back to getting the entire NAR by HTTP. Currently
such a fallback is not yet implemented.

-pukkamustard