2020-11-30 Gemini specification changes in a disagreeable way

For a moment I thought that the scheme is now mandatory in gemtext links. As it turns out, that was not the intent. In any case I’m happy to see many people on the mailing list liking scheme-less links as well. These are “network-path references” and they are cool for multi-hosting things.

Leaving the scheme away provided for a nice feature: Let’s say we have three resources: A is only reachable via Gemini, B is only reachable via HTTPS, and C is reachable by both. We’re writing gemtext that is going to be served to Gemini clients as-is and to web browsers via a simple transformation to HTML.

We can write these three links using the following:

=> gemini://A  A
=> https://B   B
=> //C         C

All URL processing clients know how to handle relative links, based on the current URL the client is looking at.

A client encountering these three links on a Gemini page links C to a Gemini resource generates the following three links:


A browser encountering these three links on a HTTPS page links C to a HTTPS resource:


The problem is that I cannot assign a scheme to C when I write the gemtext because if I do, one of the results is going to be borked: either the Gemini client sees a link to C using HTTPS or the web browser sees a link to C using Gemini, and I can’t handle it on the server side because if I use the gemini scheme for C and the server is serving a HTTPS request, then the server has to somehow know that A cannot be reached via HTTPS but C can. There is nothing in the gemtext to help the server make the decision. The only agent qualified to make this decision is the client based on the base URL.

Now, as gemtext already allows relative URLs this functionality comes “for free” (once you realize that your client has to use a decent URL parsing library).

Phoebe uses this.

For reference, see RFC 3986, “Uniform Resource Identifier (URI): Generic Syntax”.


The page used to say “Sadly, the scheme is now mandatory in gemtext. … This is unfortunate, because … I don’t see the benefit of the simplification. We’re simplifying part of the relative URL resolution and losing interesting functionality.”

– Alex

Strong agree that this is a step in the wrong dir.

– Sandra Snan 2020-11-30 17:21 UTC

Let me get this clear. So if I write “⇒ tldr.txt tldr text file” is that a valid link or not?

– Sandra Snan 2020-11-30 18:42 UTC

I was under the impression that the spec update /only/ referred to the over-the-wire requests and responses? I.e., an author could still link to //example.com, but the browser would have to resolve that to gemini://example.com (or http://example.com) before requesting it from the server. Also, the regular rules regarding URI references would apply (so Sandra’s ⇒ tldr.txt tldr would resolve to the tldr.txt in the current directory).

I hope I’m not wrong, because the way you’re writing about it is a bad direction – but I think the way I’m writing about it is the accurate picture.

– Case D (acdw), 2020-11-30 13:01 CST (UTC-6)

Let’s hope it was just people misunderstanding the email!

And yes, Sandra, that would be legal. Example:

– 2020-11-30 19:49 UTC

In that case I don’t mind. My apologies to Solderpunk.

– Sandra Snan 2020-11-30 21:38 UTC

Yeah, looks like this is going to change.

That’s what I get for uncharitable reading. I’ll make some changes to the blog post itself.

– Alex 2020-12-01 06:01 UTC

Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit the comment page if you need to fix typos. You can subscribe to new comments by email without leaving a comment.

To save this page you must answer this question:

Just say HELLO