a space case for transparent gemtext compression

[Francis Siefken]

Hi Gnuserland, you wrote today:


> As Author I have to decide if to use or not use compression, HTML/HTTP
> doesn't use compression so far I know.
>
> The HTTP protocol supports compression; for example "Content-Encoding:
zstd"
=> https://datatracker.ietf.org/doc/html/rfc8478#section-3
If both the client and server support gzip or zstd compression a compressed
stream is established. Yes this causes a developer overhead, that's why I
was happy to read compression is in TLS 1.2 and dismayed that it was
removed in TLS 1.3. While it's not removed in HTTP it warns against it's
use in certain situations, which do or do not apply in Gemini context:

=> https://datatracker.ietf.org/doc/html/rfc2616 HTTP/1.1 section on
compression
=> https://datatracker.ietf.org/doc/html/rfc7540#section-10.6 HTTP/2
compression section
=> https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#page-47
HTTP/3 compression section

It doesn't have to be difficult to mandate or implement an easy solution.

Suppose I am in a life or death situation and I am on a 300 bps link I want
the 2 kilobyte of life-saving information to be there as soon as possible.
Or you have the daily top 12 HN threads mirrored as a Gemtext file (~100
Kilobyte each) and want to read those on a 300 bps link.
Compression speeds up the process. With zstd compression and dictionary
compression https://facebook.github.io/zstd/#small-data it can be there
quicker and on low end hardware.
I think it would be elegant not to rely on having two seperate files for
this on the server, one index.gmi and one index.gmi.zstd - the Gemini
specification could allow index.gmi to be a binary and let the browser
check this after retrieval. If it's a zstd binary automatically extract and
display it.
Ofcourse keeping this poor man's content sniffing method as simple and
secure as possible.
=> https://en.wikipedia.org/wiki/Content_sniffing Wikipedia on Content
sniffing

As mentioned by others in this thread a index.gmi.zstd could also be
extracted through the existing application/zstd mime-type automatically and
display the resulting gmi inline - but as the protocol doesn't enforce this
each client can implement it differently.
To me it seems like a minimal change to the Gemini protocol to allow gmi
text to be served in zstd format and to state that the client must
decompress and display it inline instead of merely offering to download it.

Saluton,
Francis Siefken (NL)