Gemini file downloading client - a thought experiment

[Ali Fardan]

On Tue, 3 Nov 2020 22:35:14 +0100
Katarina Eriksson <gmym at coopdot.com> wrote:
> Problem A: clients don't have enough information to show a progress
> bar

It is stated in
gemini://gemini.circumlunar.space/docs/best-practices.gmi that Gemini
is not well suited for large files, and the transmission of these could
be done using an external protocol.

> Scenario 3: download a big file
> 
> Like scenario 2 except the user gets impatient enough to click the
> "show progress" button. The client makes a separate request to a
> standardized endpoint to get the needed information. If the server
> supports this standard, the information is sent and the client can
> show the progress bar to the user.

Implementing this would be tricky on the server side, this would add
unnecessary complexity, what I would suggest instead if you really
insist on using Gemini for large file transfers is specifying file size
in the link label like so:

=> gemini://example.tld/large_file.bin Download (140 MB)

and then have the client show how much of the file is downloaded, now
that you know the file size, and know how much is downloaded, you don't
need a progress indicator to be implemented within the protocol.  Of
course this is on the client to implement, but wouldn't be tricky at
all.

> Scenario 4: the TLS session terminated cleanly but we don't have full
> confidence the download succeed
> 
> Verify the file using the information we have (from scenario 3) or
> present the user with the option to fetch a hash from the
> standardized endpoint.

This does not have to be embedded in the protocol, just do this:

SHA1: ad7ff785f989c9ff9cec92bd3d0bab035a54e997
SHA256: d2af944fe8b3af5cf5a9d8c3226d06ac6369d036fc591363dedc85344bc4daa7
=> gemini://example.tld/large_file.bin Download (140 MB)

now the user can verify their downloaded file, this is done all the
time even in HTTP land.