<-- back to the mailing list

Re: ANN: go-hg — Mercury Protocol client & server library for Go programming language

Charles Iliya Krempeaux cikrempeaux at gmail.com

Mon Nov 1 08:26:12 GMT 2021

Regarding: gopher://zaibatsu.circumlunar.space/0/~solderpunk/gemini/status-codes.txt

A good example of this latter problem, IMHO, is "410 Gone" (which is

actually in the Conman Gemini server!). If this is made official in the
Gemini spec, it sends the message that Real Servers which have a Proper
Full Implementation should remember every one of their URLs which *has*
been valid in the past so it can respond to requests for them with 410
instead of 404. Similarly a Real Client should remember every 410 it gets
so that it doesn't request them again. In the real world, almost nobody
does this with HTTP, so it's basically dead weight in the spec.

And yet:https://gemini.circumlunar.space/docs/specification.html


The resource requested is no longer available and will not be available

again. Search engines and similar tools should remove this resource from
their indices. Content aggregators should stop requesting the resource and
convey to their human users that the subscribed resource is gone. (cf HTTP

I'm assuming there is some story about how this got in there.

(I wonder if it was problems with bots.)

--Charles Iliya Krempeaux, B.Sc.cikrempeaux at gmail.com

On Sun, Oct 31, 2021 at 10:27 PM Sean Conner <sean at conman.org> wrote:

It was thus said that the Great Charles Iliya Krempeaux once stated:
Hello everyone,
For me I prefer to separate out the TLS part from the server part. So,
implementation isn't an attempt to get rid of encryption, but instead a
of dividing up the technology to make it easier to work with.
I was originally doing this in a Gemini Protocol Go implementation, and
calling the TLS-free version "naked Gemini". But when I started reading
mailing list archive, and some of the gemlogs — still working through
— and noticed Mercury was the same thing, I created Go package hg.
The Mercury protocol:
was (at the time solderpunk proposed it) a thought experiement and is
actually bit less than the current Gemini-TLS---it's more akin to the
original protocol he propsed with single digit status codes [1] and a very
simple native text format. The critical part of the Mercury "spec":
3. ... then a lot of distinctions made by the remaining codes
temporary vs permanent redirects or failures) become far less
important, so we can get rid of more codes and end up below 10,
allowing them to be single digits.
4. The 'charset' parameter from the text/gemini MIME type is
and UTF-8 encoding is obligatory. The 'lang' parameter currently
under discussion for Gemini is not added.
5. The text/gemini syntax is stripped back to just two line types:
links, and plain text. Plain text lines are still wrapped by the
client, as they currently are in Gemini.
As for the requirement for TLS for Gemini, solderpunk explained his ideas
in this post:
In fact, a lot of the early history of Gemini is documented here:
[1] gopher://
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211101/1dbf68c6/attachment.htm>

Proxied content from gemini://rawtext.club/~sloum/geminilist/007485.gmi (external content)

Gemini request details:

Original URL
Status code
Proxied by

Be advised that no attempt was made to verify the remote SSL certificate.