💾 Archived View for rawtext.club › ~sloum › geminilist › 006764.gmi captured on 2024-03-21 at 16:17:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
The Gnuserland gnuserland at mailbox.org
Sun Jun 20 04:00:42 BST 2021
- - - - - - - - - - - - - - - - - - -
I am the least expert here...
But as author/user if the encryption is transparent for me, in the terms that I always upload a GMI file anyway, I don't see any real objection against but just more work for the implementers.
However the GMI is the lighter file we can think of, I really have hard time thinking any human made GMI file bigger than few kilobytes...
Thinking that a compressed capsule will save my life while modern HTTP, despite CDN, minification, etc... Will be always way more, and incomparable, bigger that any average GMI page, just makes believing that we are over-thinking about that topic!
Thanks... 😉
On June 19, 2021 12:22:49 PM EDT, Francis Siefken <fsiefken at gmail.com> wrote:
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)
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210619/69afd69a/attachment-0001.htm>