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

[Charles Iliya Krempeaux]

Regarding:
>
> The Mercury protocol:
>
>
> https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/gemlog/the-mercury-protocol.gmi
>
> 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":
>
>        [...]



        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.
>

This one feels technically challenging to enforce, since they have the same
MIME type (text/gemini).

MIME types aren't the only way to deal with types, but if one is using MIME
types, shouldn't these two different file data formats have different MIME
types?

(Or maybe I misunderstood. And it was implicitly meant for there to be a
different MIME type for this file data format.)

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



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

> It was thus said that the Great Charles Iliya Krempeaux once stated:
> > Hello everyone,
>
>   Hello.
>
> > For me I prefer to separate out the TLS part from the server part. So,
> this
> > implementation isn't an attempt to get rid of encryption, but instead a
> way
> > 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
> the
> > mailing list archive, and some of the gemlogs — still working through
> them
> > — and noticed Mercury was the same thing, I created Go package hg.
>
>   The Mercury protocol:
>
>
> https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk/gemlog/the-mercury-protocol.gmi
>
> 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
> (e.g.
>         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
> removed
>         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:
>
>         gopher://
> zaibatsu.circumlunar.space/0/~solderpunk/phlog/why-gopher-needs-crypto.txt
>
>   In fact, a lot of the early history of Gemini is documented here:
>
>         gopher://zaibatsu.circumlunar.space:70/1/~solderpunk/gemini
>
>   -spc
>
> [1]     gopher://
> zaibatsu.circumlunar.space/0/~solderpunk/gemini/status-codes.txt
>