Good netizen solderpunk has been writing about the design of a protocol that is slightly more complex than gopher, but significantly simpler than http; while at the same time being significantly more powerful than gopher. I have thoughts about this, as I’ve posted about before, and I’m interested in contributing to this project and the conversation around it. These are the main documents where they discuss it. If you only have time for one, read just the FAQ, but they are all worthwhile and short, easy reads.
(Don’t have gopher? Use the Floodgap gopher proxy from a web browser.)
- (2019-06-16) Protocol pondering intensifies, Pt I
- (2019-06-16) Protocol pondering intensifies, Pt II
- (2019-06-16) Protocol pondering intensifies, Pt III
- (2019-06-20) faq.txt
Commentary
I have basically two lines of commentary on this. The first involves authentication, and the second involves text formatting.
Authentication
As described, the protocol only supports publicly-available documents; there is no facility for documents to be behind a login-wall, for example. This may be intentional; the protocol is designed to not provide means of tracking, and authentication intrinsically implies first-party tracking. The protocol documents should either add one simple, regular, and non-extensible way of doing authentication, comparable to HTTP’s Basic Auth, or should explicitly rule out authentication.
As far as methods go, authentication could be either in-band, or out-of-band. Out-of-band methods would include things like host-based authentication (history has mostly proven this bad, and it doesn’t work well with the modern internet), or client-certificate authentication, since the protocol will use TLS (this is considered good, but also increases client complexity).
I’ve discussed in-band authentication with solderpunk, who suggests that it would be possible to overload the search parameter for a basic-auth password, but that this would mean you couldn’t have authenticated searches. My suggestion was that you could structure query strings in a manner similar to HTTP query strings, e.g.:
?auth=swordfish&search=no+more+secrets
The downside to this is that it is basically equivalent to request headers, which we’ve previously considered unnecessary. The other downside is that a server that naively logs request paths with query strings will expose passwords in logs; servers will have to be smart enough to only log the actual search part.
Text Formatting
In part III, solderpunk discusses the text file format to be used as it relates to navigation. In one way, it’s not really necessary to discuss this: the protocol can serve any kind of media, be it text/plain, text/html, text/x-markdown, or text/x-vnd-msword. But in another way, it’s important to set expectations about what will normally be served, and what clients should implement internal support instead of deferring to external helpers.
Solderpunk recommends a format similar to what people are using right now for gophermaps: selectors on lines by themselves, but plain text everywhere else. In gophernicus, e.g., this gets transformed into a map with selectors on every line, but most of them are the non-standard “i” type for a line of text.
Personally, I quite like Markdown, but the pain point of Markdown is that it’s actually sometimes ambiguous and therefore hard to parse. There are libraries for it in every widely used language, but those libraries generally only render it to HTML, which is useful, but not for a hypothetical gemini client.
A possible good alternative is Text Junior (see also), a format created by phlogger ratfactor. It is similar to Markdown, but purely line-oriented, which makes it unambiguous and easy to parse. It unfortunately lacks character-oriented formatting like emphasis and strong emphasis, because of the ambiguity issues. But this could possibly be resolved by not letting character-oriented formatting span source lines.
Addendum
Since I started writing this a couple of days ago, solderpunk has expanded their discussion on Project Gemini and separated it out into its own phlog section..
Also, Alex Schroeder has responded with his concerns on various issues.