It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Fri, Feb 28, 2020 at 4:44 AM Sean Conner <sean at conman.org> wrote:
> > I disagree. Using "proper symbols" is over all harder to deal with.
> > First, it tends to be English-centric. I mean, we could go with:
> >
> > defectum:tempus:tardius
> >
> > or how about
> >
> > teip:sealadach:n?os-moille
>
>
> The protocol is already English centric, for example the MIME types
> (which are IANA standards), it uses lef-to-right writing, it uses
> UTF-8 which is optimized for Latin-based alphabets, etc.; so if we
> want to be politically correct, we could use Latin or Esperanto.
Why is a numeric status code so bad? Yes, the rest of the protocol is
English centric (MIME types; left-to-right, UTF-8). It just seems that
using words (regardless of language) is just complexity for its own sake.
> OK, although I understand why things are harder in C, you present
> above only the "easy part". Please take into account the
> line-reading, splitting into code and meta (and the protocol does say
> one or multiple whitespaces in between), checking the `CRLF` at the
> end. Now assuming you've done all that even the code above has a
> couple of bugs:
> * what if the server sends `99`? (it is not covered);
> * what if the server sends just `6`? (it is not covered, although
> given that perhaps `status` is `\0` terminated it won't be a large
> problem, but still it would fall through;)
> * what if the server just sends an empty status code? (is it checked
> by the parser?)
Oh, thanks for the client test suggestions. I'll need to add those to my
client torture test (for a client, I would expect it to just reject the
response and indicate a server error to the user).
> As minor issues:
> * why `CRLF`? it's easier (both in terms of availability of functions
> and efficiency) to split lines by a single character `\n` than by a
> string;
That was discussed earlier on the list:
gemini://gemi.dev/gemini-mailing-list/messages/000116.gmi
> * why allow "one-or-more whitespaces" especially in protocol related
> parts? why not mandate a strict syntax?
solderpunk will have to answer that one.
> > > On a second thought, why TLS? Why not something based on NaCL /
> > > `libsodium` constructs, or even the "Noise Protocol"
> > > (http://www.noiseprotocol.org/)?
> >
> > 1) Never, *NEVER* implement crypto yourself.
>
> I was never proposing to implement crypto ourselves. `libsodium` /
> NaCL provides very useful high-level constructs, tailored for specific
> use-cases (like for example message encryption and signing), that are
> proven to be safe, and exports them with a very simple API that can be
> easily understood and used.
TLS was choosen because the COMMUNICATIONS LINK is encrypted, not just the
payload. All Eve (the evesdropper) can see is what IP address you are
connecting to, not what content you are reading, nor (depending upon the TLS
version) what virtual server you might be talking to.
> > 2) OpenSSL exists and has support in most (if not all) popular
> > languages.
>
> Don't know what to say... I find the OpenSSL documentation terrible,
> and it's hard to use... In fact given the complexity of TLS I would
> say any wrapper, reimplementation, or alternative is as bad. For
> example I played with Go's TLS library and even though it's manageable
> it requires lots of attention to get things right.
Yes, it is horrible. And people make do. I know for myself I'm using
libtls, which is part of LibreSSL (a fork of OpenSSL) which makes using TLS
trivial. I was able, with just the header file tls.h and man pages, wrap
libtls for Lua [1], which I use for my Gemini server GLV-1.12556 [2]. I
just wish libtls was more widely available.
> > > Why not just re-use PGP to sign / encrypt requests and replies? With
> > > regard to PGP,
> >
> > There are issues with using PGP:
> >
> > https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
>
> There are issues with any technology, TLS included.
>
> However I would say it's easier to integrate GnuPG (even through
> subprocesses) in order to encrypt / decrypt payloads (especially given
> how low in count they are for Gemini's ecosystem) than implementing
> TLS. Moreover it offers out-of-the-box the whole client side
> certificate management, which adding to a TLS-based client would be
> much more involved, more on this bellow...
As I have mentioned, that only protects the payload, not the
communications channel.
> > The hardest problem with crypto is key management. If anything, key
> > management with PGP seems more problematic than with OpenSSL and the CA
> > infrastructure (as bad as the CA infrastructure is).
>
> One of the `gemini://` specifications explicitly states that the
> server certificate authentication model is similar to SSH's first use
> accept and cache afterward. However say you'll go with the actual CA
> model, now you need to juggle Let's Encrypt (each 3 months) (or add
> support for ACME in your server), then juggle PEM files, etc.
> Regardless, either way one will have to implement all this certificate
> management from scratch.
Or self-signed certificates.
Okay, we use NaCL. Now what? What's needed to secure the communication
channel? A key exchange. Again, rule 1---never implement crypto.
> > Forms lead to applications. Applications lead to client side scripting.
> > Client side scripting leads to the web ...
> >
> > Of course there's pressure to expand the protocol. solderpunk is trying
> > his hardest to keep that from happening and turning Gemini into another web
> > clone.
>
>
> But you are already implementing "applications" on-top of Gemini (and
> Gopher) through CGI...
Yes ... but there's only two Gemini servers that support CGI, GLV-1.12556
[2] and Jetforce [3] (two out of five Gemini server programs). I
implemented CGI in GLV-1.12556 just because I could (and I think to prove a
point). I technically don't need CGI support for the server I run since
it's just as easy for me to implement custom handlers [4].
> > > Regarding an up-to-date Gopher map alternative, I think this is an
> > > important piece of the Gopher ecosystem that is missing from today's
> > > world: a machine-parsable standard format of indexing documents. I
> > > very fondly remember "directory" sites of yesteryear (like DMOZ or the
> > > countless other clones) that strives to categorize the internet not by
> > > "machine learning" but by human curation.
> >
> > Could you provide an example of what you mean by this? I'm not sure why a
> > map alternative is needed.
>
> One problem with today's web is that the actual "web structure" is
> embedded in unstructured documents as links. What I liked about
> Gopher maps is that it gave a machine-readable, but still
> user-friendly, way to map and categorize the "web contents".
One problem with that---incentives. What's my incentive to make all this
information more easily machine readable? On the web, you do that, and what
happens? Google comes along, munches on all that sweet machine readable
data and serves it up directly to users, meaning the user just has to go to
Google for the information, not your server. Given those incentives, I have
no reason to make my data easily machine readable when it means less
traffic.
I recall the large push for RDF (Resource Description Framework) back
around 2004 or so ... embed machine parsable relations and metadata and it
would be oh so wonderful. Some people even bothered to to all that work.
And for what? It was a pain to maintain, the tooling was poor, and Google
would just suck it up and serve it to users directly, no reason for anyone
to actually visit your site.
As a user, that's great! As a web site operator, not so much.
> > > * and perhaps add support for content-based addressing (as opposed to
> > > server-based addressing) (i.e. persistent URL's);
> >
> > There already exist such protocols---I'm not sure what a new one based
> > around Gemini would buy.
>
> I agree that `gemini://` is first and foremost a "transfer" protocol.
> However one can include a document's identity as a first class citizen
> of the protocol.
>
> For example say each document is identified by its SHA; then when
> replying with a document also send that SHA in form of a permanent URL
> like say `gemini-object:?sha={SHA}&location=gemini://first-server/...&loc
ation=gemini://second-server/...`;
> then a client (that perhaps has bookmarked that particular version of
> that document) could send that URL to a server (of his choosing via
> configuration, to the first one specified in `location`, etc.) and if
> that server has that document just reply with that, else use
> `location`, else return 404.
Hey, go ahead and implement that. I'd like to see that ...
-spc (I got my feet wet in Gemini by implementing the first server ... )
[1] https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c
[2] https://github.com/spc476/GLV-1.12556
[3] https://github.com/michael-lazar/jetforce
[4] gopher://gopher.conman.org/1Gopher:Ext:GLV-1/handlers/
---
Previous in thread (3 of 17): 🗣️ Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)
Next in thread (5 of 17): 🗣️ Sean Conner (sean (a) conman.org)