💾 Archived View for rawtext.club › ~sloum › geminilist › 001276.gmi captured on 2020-11-07 at 02:06:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Pete D. peteyboy at SDF.ORG
Tue Jun 2 22:55:35 BST 2020
- - - - - - - - - - - - - - - - - - -
Message: 1
Date: Tue, 2 Jun 2020 20:00:42 +0000
From: solderpunk <solderpunk at SDF.ORG>
To: Gemini application layer protocol <gemini at lists.orbitalfox.eu>
Subject: Re: approachabe & frugal & composable
Message-ID: <20200602200042.GC11961 at SDF.ORG>
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 02, 2020 at 09:09:47PM +0200, Petite Abeille wrote:
Either a client understands an URI scheme, say http/https, and knows what to do with it (e.g. turn it into an interactive hyperlink of sort, pretty print it somehow, etc), or it doesn't, in which case just display it 'as is'.
In short, only decorate scheme you know, leave the rest alone, and render it as static text.
Never hide anything.
Put another way, text/gemini is fundamentally text. Nothing more, nothing less. And that's good enough for a minimal client.
More advance clients could choose to render links to the best of their abilities, say gemini:// links are turned into navigational aids of sort.
And that is that.
This sounds "short and sweet" and simple, but this basically makes
Gemini infinitely extensible. Link lines stop having anything to do
with the concept of "links", and become vehicles for anything that
somebody wants to come up with a URI scheme for, which is a large and
totally open category which will grow over time and may come to include
very scary things (for the love of God, there was an IETF draft for a
javascript: scheme! [1]). Giving clients the power to recognise any old
scheme which comes along is guaranteed to induce a repeat of the
evolution of the web. Basically we can now think of the line:
=
scheme:restofuri Human friendly label
as equivalent to something like:
<scheme arg1="restofuri" arg2="Human friendly label"/>
text/gemini would be fully as extensible as HTML where client authors
can just invent new tags like <blink> and <marquee>. It's exactly what
nobody here wants.
I am *so angry* that there isn't a construct in the internet
architecture which is *nothing more* than a convenient way to concisely
specify an application protocol, a hostname or IP address, a port, and
a path. This is such an obviously useful thing to have. It's what
almost everybody *thinks* a URL is, but it turns out that's wrong. Who
would have thought that Gopher's clunky and archaic notation of:
path<TAB>hostname<TAB>port<TAB>
literally has not been improved on in ~30 years?
At this point I am honestly considering speccing that =
lines may
*only* use URLs whose scheme corresponds to an application protocol.
Permitting *any* RFC-compliant URL is just way, way too open-ended and
defeats the point of so much careful efforts elsewhere in the protocol.
Cheers,
Solderpunk
I feel like what's been revealed here is that you have little control of this the way it's designed. You could eschew URIs for your own format, but then it would be just harder than it is now to use off-the-shelf tools to "pervert" gemini, but still possible. It could also be that people fork into another protocol. In the end, the browser can be handed something by a server, and if the browser and server are both consenting programs, they'll do what they want. And if enough people think it's cool, there will be more of those servers, more of that content, and then more of those browsers. This is what happened to http://, isn't it? How Netscape defeated Mosaic?
Some of the excitement around gemini feels like it's because it's a rebooting of http. I definitely feel it some myself. I like the aesthetic, though, and the idea behind it. The reality is, too, that if people extend gemini into another http, it will just be not-as-good http.
But can you stop people from super-setting gemini?
PS reading all this gemini stuff makes me want to create a "wiki://" scheme, like native super-wiki web