-- Leo's gemini proxy

-- Connecting to git.thebackupbox.net:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

repo: gemini-site
action: commit
revision:
path_from:
revision_from: 1c2e9e3f6757fe7ffe5b012e5dbc628325eaa1c4:
path_to:
revision_to:

git.thebackupbox.net

gemini-site

git://git.thebackupbox.net/gemini-site

commit 1c2e9e3f6757fe7ffe5b012e5dbc628325eaa1c4
Author: Solderpunk <solderpunk@posteo.net>
Date:   Sun Nov 1 14:29:29 2020 +0100

    FAQ updates.

diff --git a/docs/faq.gmi b/docs/faq.gmi

index 07558bcbbebc80c1404256ffe0262a481bf3f804..

index ..76916c6396db6f27935588b83c6bfeae20b47cfc 100644

--- a/docs/faq.gmi
+++ b/docs/faq.gmi
@@ -124,7 +124,16 @@ Of course, even a "from scratch" Gopher client actually depends crucially on tho

 Gemini also turns TLS client certificates - very rarely seen on the web - into a first-class citizen with in-band signalling of their requirement.  This allows restricting access to Gemini resources to certain parties, or voluntarily establishing "sessions" with server-side applications, without having to pass around cookies, passwords, authentication tokens or anything else you may be used to.  It's much closer to SSH's notion of "authorized keys" and is, in fact, a much simpler approach to user authentication.

-## 2.8 Why didn't you just use Markdown instead of defining text/gemini?
+## 2.8 Why use TLS for crypto instead of something more modern like the Noise protocol?
+
+TLS is certainly not without its shortcomings, but:
+
+* There are bindings to TLS libraries available for almost every programming language under the sun
+* Many developers are already at least partially familiar with TLS and therefore don't need to learn anything new to implement Gemini
+* Most users are already trusting TLS to secure their web browsing and email, and therefore don't need to decide whether or not they want to trust some unfamiliar technology to start using Gemini
+* TLS is a deeply entrenched industry standard, whose definition and implementations will both continue to be scrutinised and improved by security experts for the foreseeable future, and that work will happen for reasons entirely unrelated to Gemini - it makes a lot of sense for a small project to "freeride" like this.
+
+## 2.9 Why didn't you just use Markdown instead of defining text/gemini?

 The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini?  Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages".  Reasons not to go down this route include:

@@ -135,7 +144,29 @@ The text/gemini markup borrows heavily from Markdown, which might prompt some pe

 Of course, it is possible to serve Markdown over Gemini.  The inclusion of a text/markdown Media type in the response header will allow more advanced clients to support it.

-## 2.9 Why don't you care about retrocomputing support?
+## 2.10 Why doesn't text/gemini have support for in-line links?
+
+Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation.  Therefore, it is important that the format is extremely simple to handle correctly.  The line-based format where text lines and link lines are separate concepts achieves this.  There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax.  Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients).  Even though in-line links may be a more natural fit for some kinds of content, they're just not worth the increased complexity and fragility they would inevitably introduce to the protocol.
+
+It's true that you need to shift your thinking a bit to get used to the one link per line writing style, but it gets easier over time.  There are benefits to the style as well.  It encourages including only the most important or relevant links, organising links into related lists, and giving each link a maximally descriptive label without having to worry about whether or not that label fits naturally into the flow of your main text.
+
+## 2.11 Why isn't there an equivalent of the HTTP Content-length header?
+
+Non-extensibility of the protocol was a major design principle for Gemini.  Things like cookies, Etags and other tracking tools were not present in the origial design of HTTP, but could be seamlessly added later because the HTTP response format is open-ended and allows the easy inclusion of new headers.  To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to included one and exactly one piece of information in the response header for successful requests.  Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again.  There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality.  Given this restriction, including only an equivalent of Content-type seemed clearly more useful than including only an equivalent of Content-length.  The same is true for other harmless and useful HTTP headers, like Last-Modified
+
+Gopher also has no equivalent of the Content-length header, and this has not proven to be a practical obstacle in Gopherspace.
+
+Even without this header, it is possible (unlike in Gopher) for clients to distinguish between a Gemini transaction which has completed successfully and one which has dropped out mid-transfer due to a network fault or malicious attack via the presence or absence of a TLS Shutdown message.
+
+It is true that the inability for clients to tell users how much more of a large file still has to be downloaded and to estimate how long this may take means Gemini cannot provide a very user-friendly experience for large file downloads.  However, this would be the case even if Content-length were specified, as such an experience would also require other complications to be added to the protocol e.g. the ability to resume interrupted downloads.  Gemini documents can of course straightforwardly link to resources hosted via HTTPS, BitTorrent, IPFS, DAT, etc. and this may be the best option for very large files.
+
+## 2.12 Why isn't a protocol version number included with requests or responses?
+
+This would only be useful if there were plans to smoothly upgrade to a "Gemini 2.0" in the future - and there aren't!  Gemini is a "less is more" reaction against web browsers and servers becoming too complicated and too powerful.  It makes no sense to plan to add more functionality to Gemini later.  Instead the plan is to "get it right the first time", as much as possible, then freeze the protocol specification forever after, without upgrades, enhancements or extensions.
+
+This may seem radical or unwise, but we're cautiously optimistic.  The Gopher specification has not been changed in about 30 years, and only a very small number of quite minor unofficial changes to that spec are in common use in today's Gopherspace, which is actually growing in popularity.  Gemini combines mature, ubiquitous internet primitives like URIs, MIME media types and TLS in a very straightforward way, and seeks to foster a culture of working within - and even embracing - carefully chosen limitations, rather than removing each constraint as it is encountered to make anything possible.  There are plenty of things that Gemini is useful for and good at right now, and there is no reason to think it won't be useful for and good at those same things decades from now.
+
+## 2.13 Why don't you care about retrocomputing support?

 Gopher is so simple that computers from the 80s or 90s can easily implement the protocol, and for some people this is one of the great virtues of Gopher.  The TLS requirement of Gemini limits it to more modern machines.

-----END OF PAGE-----

-- Response ended

-- Page fetched on Sun Jun 2 17:34:58 2024