💾 Archived View for rawtext.club › ~sloum › geminilist › 006752.gmi captured on 2023-09-28 at 16:40:04. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

a space case for transparent gemtext compression

Francis Siefken fsiefken at gmail.com

Sat Jun 19 13:49:19 BST 2021

- - - - - - - - - - - - - - - - - - - 

Hi Christian, on Sa 19 jun 2021 11:48 you wrote:

you can make suggestions to skyjake on Station or on the lagrange github[..]
compressed single files can absolutely be instantly decompressed by aclient that implements this.
Also, if TLS 1.3 has compression (thanks for telling me that, I didn'tknow that),
then it makes supporting specific compressions in clients unnecessary,because we
are going to be switching to TLS 1.3 in the future, from what I'vegathered.

I am sorry I misinformed you, TLS 1.2 has compression (for exampledeflate), but in TLS 1.3 it has been removed. But it introduces certificatecompression to save handshake time. Although it's understandable because ofthe various exploits it's unfortunate as in my opinion there are use cases,like SMTP or Gemini where it makes sense and where it's not a risk. I'llmake suggestions for browser handling of compressed individual Gemtexts.Just like the TLS 1.3 design committee thinks about saving time with thehandshake, and compressing a certificate the size of Gemtext. I dreamabout saving time with optional zstandard or ppmd compression in the Geminiprotocol. Making it a user or browser choice is second best. Perhaps Geminican stay on TLS 1.2 forever?

Kind regards,Francis Siefken (NL)gemini://fsiefken.srht.site-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210619/da611d5b/attachment.htm>