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.

Beginning of the thread on the mailing list

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:

gemini://A
https://B
gemini://C

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

gemini://A
https://B
https://C

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.

Phoebe

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

​#Gemini

Comments

(Please contact me if you want to remove your comment.)

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).

gemini://example.com

http://example.com

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.

– 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.

Mail by Solderpunk

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