Regarding `gemini://` over NaCL (replacing TLS)

[Michael Lazar]

> It was thus said that the Great Bradley D. Thornton once stated:
> > On 3/1/2020 4:18 PM, Sean Conner wrote:
> > >
> > > 2) As I feared, this requires a more complicated implementation.  solderpunk
> > > wanted a protocol that could be implemented quickly and while TLS might be a
> > > bad protocol, it at least has the feature of being widely available and
> > > largly transparent if done correctly (like libtls, part of LibreSSL, does).
> >
> > um.... <smile>, Sean I have to call attention here to the fact that such
> > an implementation of security isn't actually as simple as you portray in
> > that statement, lolz...
> >
> > For example, just a couple of days ago you touted the libtls that you
> > [were able to] took advantage of, as a result of developing GLV-1.12556
> > being written in Lua ;)
> >
> > In fact, you posted a tiny snippet of text showing how simple it was (in
> > that language), lending in part, to the simplicity of a Gemini server
> > being possible as a result of a weekend coding and beer session.
> >
> > On the other hand, I recall quite clearly, Michaels encyclopedic
> > lamentations on the vagaries of attempting to acheive successful results
> > in Python, with regards to TLS and client/transient certs, due to the
> > horrendous state of Python libs in that regard :)
>
>   Do you have any links to this?  I don't remember seeing any of that, and
> I'd be interested in reading it.

I believe this is referencing this post that I made a while ago [1].

Personally, I would rather have gemini:// not be encrypted at all. I know
there is a subset of privacy conscious users who are super dogmatic about
security and E2E encryption. This much is clear from watching the gopher
community. But I am not one of those users, and that is not what excites me
about the gemini protocol.

[1] gemini://mozz.us/journal/2019-08-21_transient_tls_certs.gmi

- mozz