a space case for transparent gemtext compression

Omar Polo op at omarpolo.com
Sat Jun 19 11:51:28 BST 2021

Christian Seibold <krixano at mailbox.org> writes:

> Let me repeat this... adding compression to clients in the way that
> has been described in this thread does NOT break geminispace.

I'm not too too sure about this.  As I see it, using *any* file type
other than text/gemini as default choice for the content will break the

Gemini browser have to implement text/gemini[0], not text/gemini+gzip,
text/html or text/x-markdown, and if text/gemini+gz (or whatever) starts
to gain a bit of popularity it *will* break the geminispace IMHO.

> Gemini deliberately allows you to send whatever you want over. It's a
> file-transfer protocol. Using the mimetype is *exactly* what I
> proposed. Period. End of discussion.

and I totally agree with you here.  You can serve any type of content
over Gemini, so what's all this fuss about?  You have a strange use case
where you need compression?  Fine, you can do it.  Good for you.  But
please don't waste our time by telling how much cool would be to change
every browser just to read the usual 1-2K[1] pages.


Omar Polo

P.S.: I don't want to sound too harsh, in fact I have a local patch for
      gmid to allow the `entrypoint' config option inside `location'
      blocks, so that for instance one can do something like

	server "xyz.com" {
		location "*.gmi.gz" {
			entrypoint "/my/gzip/script";

      to automatically generate gzipped files (using an hypotetical CGI
      script in /my/gzip/script) on the fly[2].

[0]: OK, not quite really, gemget/curl-like applications only implement
     the protocol, but I'm talking about more "user-facing" browsers.
[1]: Stephane Bortzmeyer once shared with us the mean size of
     text/gemini pages as computed by lupa IIRC.
[2]: actually, this will allow to generate *any* file on the fly, that's
     why I added it.

More information about the Gemini mailing list