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:
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.
For reference, see RFC 3986, “Uniform Resource Identifier (URI): Generic Syntax”.