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@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.
---
Previous in thread (44 of 50): 🗣️ Rohan Kumar (seirdy (a) seirdy.one)
Next in thread (46 of 50): 🗣️ Peter Mucha (ptmucha (a) gmail.com)