Somewhat interesting takes by Daniel Stenberg (curl author)
https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/

Julien Blanchard wrote:

> Somewhat interesting takes by Daniel Stenberg

Let's face it, there is probably more data transferred every millisecond
by https than has ever been transferred by gemini ...

On 6/5/23 04:14, Julien Blanchard wrote:
> Somewhat interesting takes by Daniel Stenberg (curl author)
> https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/

I'd go so far as to say it's more than ``interesting'' takes. There's
actually some very good, and valid criticism of Gemini, while
acknowledging that it's not the ultra-general
do-everything-but-do-nothing-well protocol that https is.

But I did want to point out that anyone who thinks Gemini documents
aren't attractive is either using the wrong client, or just hasn't
configured it to suit their tastes. I'm not the biggest Gemini user out
there, but every capsule I've seen (in Lagrange) looks great.

> This is not a protocol designed for the masses to replace anything at
high volumes. That is of course totally fine and it can still serve its
community perfectly fine.

I think this portion of the article really highlights what Gemini is
about, even if David doesn't ``get it'' (And it's totally fine that he
doesn't! It's not for everyone!).

rdh <rdh@tilde.institute> writes:

> On 6/5/23 04:14, Julien Blanchard wrote:
>> Somewhat interesting takes by Daniel Stenberg (curl author)
>> https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/
>
> I'd go so far as to say it's more than ``interesting'' takes. There's
> actually some very good, and valid criticism of Gemini, while
> acknowledging that it's not the ultra-general
> do-everything-but-do-nothing-well protocol that https is.
>

I found Daniel's analysis valuable as usual.

Having read the spec and played with the protocol, I'm not clear as to
whether Gemini does any particular thing better than HTTP does. The
*protocol* itself seems to be largely "HTTP GET requests with the lowest
byte chopped off the response code, and we hang up after one response".

Since the protocol can return various media types it's not particularly
necessary to discuss the text/gemini media type in conjunction with the
Gemini protocol -- you could certainly serve text/gemini over HTTP, and
although I can't find any indication it's got much client support yet,
there's not a thing in the world preventing somebody from serving plain
old HTML pages over the Gemini protocol too, complete with images loaded
in, JS, CSS, etc. However, since discussion of Gemini and text/gemini
*typically* occurs in the same breath, I'll say that the author should
have just gone ahead and used Markdown as-is instead of taking a subset
but defining an odd Gopher-imitating rule specifically for links.

john

John <john@building-m.simplistic-anti-spam-measure.net> writes:

> rdh <rdh@tilde.institute> writes:
> Since the protocol can return various media types it's not particularly
> necessary to discuss the text/gemini media type in conjunction with the
> Gemini protocol -- you could certainly serve text/gemini over HTTP, and
> although I can't find any indication it's got much client support yet,
> there's not a thing in the world preventing somebody from serving plain
> old HTML pages over the Gemini protocol too, complete with images loaded
> in, JS, CSS, etc. However, since discussion of Gemini and text/gemini
> *typically* occurs in the same breath, I'll say that the author should
> have just gone ahead and used Markdown as-is instead of taking a subset
> but defining an odd Gopher-imitating rule specifically for links.

Yip. Protocols and text formats should be looked at independently and
real browsers support lots of both. Not the web is broken, "modern"
browsers are. They degrade to single protocol network file viewers.

Try <gopher://sdf.org/0/users/yeti/more-experiments.gmi> with elinks
<https://github.com/rkd77/elinks> or elpher. index.gmi would work too,
but some "font" might not render well in terminal clients. With GUIy
elpher it looks ok. Throwing HTML files into my combined gopher/gemini
dir @SDF would be doable, I just haven't done it yet.

--
Take Back Control! -- Mesh The Planet!
I do not play Nethack, I do play GNUS! o;-)
Solid facts do not need 1001 pictures.

yeti <yeti@tilde.institute> writes:

> John <john@building-m.simplistic-anti-spam-measure.net> writes:
>
>> rdh <rdh@tilde.institute> writes:
>> Since the protocol can return various media types it's not particularly
>> necessary to discuss the text/gemini media type in conjunction with the
>> Gemini protocol -- you could certainly serve text/gemini over HTTP, and
>> although I can't find any indication it's got much client support yet,
>> there's not a thing in the world preventing somebody from serving plain
>> old HTML pages over the Gemini protocol too, complete with images loaded
>> in, JS, CSS, etc. However, since discussion of Gemini and text/gemini
>> *typically* occurs in the same breath, I'll say that the author should
>> have just gone ahead and used Markdown as-is instead of taking a subset
>> but defining an odd Gopher-imitating rule specifically for links.
>
> Yip. Protocols and text formats should be looked at independently and
> real browsers support lots of both. Not the web is broken, "modern"
> browsers are. They degrade to single protocol network file viewers.

I'm still kind of blown away by the removal of FTP support from the big
browsers...

> Try <gopher://sdf.org/0/users/yeti/more-experiments.gmi> with elinks
> <https://github.com/rkd77/elinks> or elpher. index.gmi would work too,
> but some "font" might not render well in terminal clients. With GUIy
> elpher it looks ok. Throwing HTML files into my combined gopher/gemini
> dir @SDF would be doable, I just haven't done it yet.

Yeah, at least on my emacs, a good chunk of the text is unicode tofu on
index.gmi

I tried HTML over gemini in elinks a while back and IIRC it worked
pretty well but of course I couldn't really test how it handled img
tags.

john

On Wed, 26 Jul 2023 16:13:53 +0000, John wrote:

> rdh <rdh@tilde.institute> writes:
>
>> On 6/5/23 04:14, Julien Blanchard wrote:
>>> Somewhat interesting takes by Daniel Stenberg (curl author)
>>> https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-
this-http-client-person/
>>
> I found Daniel's analysis valuable as usual.

Full ack; explaining well it won't be in curl with its formal
deficiencies.
> Having read the spec and played with the protocol, I'm not clear as to
> whether Gemini does any particular thing better than HTTP does.

Using client certificates to authenticate as user to some service provided
by a capsule seems very elegant to me.

> Since the protocol can return various media types it's not particularly
> necessary to discuss the text/gemini media type in conjunction with the
> Gemini protocol -- you could certainly serve text/gemini over HTTP, and
> although I can't find any indication it's got much client support yet,
> there's not a thing in the world preventing somebody from serving plain
> old HTML pages over the Gemini protocol too, complete with images loaded
> in, JS, CSS, etc. However, since discussion of Gemini and text/gemini
> *typically* occurs in the same breath, I'll say that the author should
> have just gone ahead and used Markdown as-is instead of taking a subset
> but defining an odd Gopher-imitating rule specifically for links.

I'm kinda disappointed Firefox does not render Markdown (which flavour
though …) natively. But then, web browsing would still only be a mixed
experience of some text-based Markdown articles among other bloated stuff.
Basically what we still have with the blogosphere.

With being somewhat tied to the odd text/gemini media type Gemini spans
its very own space, where users know what to expect visually – attracting
a surprising large user base.

On Wed, 26 Jul 2023 18:14:43 -0000 (UTC), Plain Text wrote:
> Using client certificates to authenticate as user to some service
> provided by a capsule seems very elegant to me.

FWIW, this works just fine with HTTPS, most people don't use it but I
assure you that your favorite web browser almost certainly has a UI
to specify a client SSL/TLS certificate when requested by the remote
server. I seem to recall using it for $WORK Intranet sites in the
early 00's using Netscape.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh

On 2023-07-26, rdh <rdh@tilde.institute> wrote:
> On 6/5/23 04:14, Julien Blanchard wrote:
>> Somewhat interesting takes by Daniel Stenberg (curl author)

Thanks for sharing, reading now.

Is good to have opinions and educated critizism, makes things get
better(most times)

ReK2
Happy Hacking

--
{gemini,https}://{,rek2.}hispagatos.org
https://hispagatos.space/@rek2

rek2 hispagatos <rek2@hispagatos.org.invalid> writes:

> On 2023-07-26, rdh <rdh@tilde.institute> wrote:
>> On 6/5/23 04:14, Julien Blanchard wrote:
>>> Somewhat interesting takes by Daniel Stenberg (curl author)
>
> Thanks for sharing, reading now.
>
> Is good to have opinions and educated critizism, makes things get
> better(most times)
>

The irony is palpable.

john

On 2023-07-28, John <john@building-m.simplistic-anti-spam-measure.net> wrote:
> rek2 hispagatos <rek2@hispagatos.org.invalid> writes:
>
>> On 2023-07-26, rdh <rdh@tilde.institute> wrote:
>>> On 6/5/23 04:14, Julien Blanchard wrote:
>>>> Somewhat interesting takes by Daniel Stenberg (curl author)
>>
>> Thanks for sharing, reading now.
>>
>> Is good to have opinions and educated critizism, makes things get
>> better(most times)
>>
>
> The irony is palpable.
>

XD XD XD :)

--
{gemini,https}://{,rek2.}hispagatos.org - mastodon: @rek2@hispagatos.space
[https|gemini]://2600.Madrid - https://hispagatos.space/@rek2

> The reduced complexity however also makes it less visually pleasing
> to users and by taking shortcuts in the protocol, it risks adding
> complexities elsewhere instead.

The document should not be designed to be "visually pleasing" to users;
it is not a printed document, but a computer and it can be customized
by the end user. The appropriate presentation can depend on user
preferences and on device capabilities, and the document itself should
not have to care about either.

I agree some shortcuts in the protocol risk some complexities though,
but the visual appearance of the document isn't relevant here.

> There is nothing written about how a client should deal with the
> existing query part in this situation. Like if you want to send a
> query and answer the prompt.

What I would do is just append another question mark and the input,
although perhaps servers need not do such a thing and instead include
the existing data in the path name and file name instead.

> Split the spec into three separate ones: protocol, URL syntax, media
> type. Expand the protocol parts with more exact syntax descriptions
> and examples to supplement the English.

Here I agree, although the documents should be put together that you can
easily find all of them, since they would commonly be used together.
(Actually, the protocol and URL are even related to each other because
of the protocol working requiring the URL.)

Note that on my computer I have implemented text/gemini over HTTP(S) and
local files, although the Gemini protocol does not work yet.

> Clarify the client certificate use to be origin based, not host name.

Yes, that would be helpful.

> Drop the TOFU idea, it makes for a too weak security story that does
> not scale and introduces massive complexities for clients.

I am not sure what to do, but I agree that TOFU is no good. I think
user-configurable is helpful, to define your own trusted certificates;
the defaults can be used like Lets Encrypt, etc, I suppose. (The end user
could still override if necessary; e.g. in curl, use the -k switch.)

One thing I would do is drop mandatory TLS (and define a different URI
scheme for the cleartext version, but the same port number can be used,
although they should then fix stunnel to support this possibility). Note
that client certificates will not work with the cleartext protocol; if a
document requires a client certificate to access, then it can redirect
to the secure protocol (and should not do that otherwise). The server
SHOULD treat both URI schemes as equivalent but the client MUST NOT do
so (the client MUST NOT automatically decide whether or not to use the
secure protocol based on anything other than the URI scheme).

> Clarify the UTF-8 encoding requirement for URLs. It is confusing and
> possibly bringing in a lot of complexity. Simplify?

I would get rid of this requirement completely. The URL is just ASCII.
It may contain bytes beyond ASCII too (usually percent encoded). A
client MAY treat entered URLs as UTF-8 for this purpose.

Another possible meaning of this is URLs inside of documents. If a
document is not encoded as UTF-8 and contains a link which contains
non-ASCII characters which have not been percent-encoded, to be
converted to UTF-8. However, there are problems with this and with
conversion between character sets anyways. My recommendation for this
is that URLs in documents should always be in ASCII format (and if
non-ASCII characters are needed, use percent-encoding).

For the domain name, also use ASCII. This also improves security as
well as simplification. A client MAY convert entered non-ASCII domain
names into Punycode (or display an error message).

(Note that many people seem to think that Unicode is good without really
understanding it, and without understanding multilingual handling and
character sets and encodings. My own programs and files do not use Unicode
and avoid Unicode as much as possible, even for multilingual text (which I
do sometimes deal with). I also think that computer commands should use
ASCII, even if the document isn't.)

> Clarify how proxying is actually supposed to work in regards to TLS and
> secure connections. Maybe drop the proxy idea completely to keep the
> simplicity.

I agree to drop the proxy idea. This also goes with dropping mandatory TLS,
since without TLS also will be without SNI, and the domain name given in the
URL can be used instead (like the HTTP "Host" header).

> Consider a way to re-use connections, even if that means introducing some
> kind of "chunks" HTTP-style.

I think Gemini protocol is simple for such a thing and is designed to be
simple to not have them.

Another thing missing is the file size in the header (if known; sometimes
the file size might not be known, but if it is known then it is helpful).

--
Don't laugh at the moon when it is day time in France.

John <john@building-m.simplistic-anti-spam-measure.net> writes:

> Having read the spec and played with the protocol, I'm not clear as to
> whether Gemini does any particular thing better than HTTP does. The
> *protocol* itself seems to be largely "HTTP GET requests with the lowest
> byte chopped off the response code, and we hang up after one response".

There's nothing that the Gemini protocol does *strictly* better than
HTTP. It's equivalent to HTTP 0.9 GET over TLS. Most of Gemini's
features should be seen as solutions to problems with Gopher. That said,
the thing that makes Gemini desirable relative to HTTP is
non-extensibility. The presence of headers in HTTP requests is an
obvious place to complicate things, and from HTTP 1.0 to HTTP 1.1 saw a
huge proliferation of headers that required special handling on client,
server, or both. Gemini offers you no place to put those things.

> Since the protocol can return various media types it's not particularly
> necessary to discuss the text/gemini media type in conjunction with the
> Gemini protocol -- you could certainly serve text/gemini over HTTP, and
> although I can't find any indication it's got much client support yet,
> there's not a thing in the world preventing somebody from serving plain
> old HTML pages over the Gemini protocol too, complete with images loaded
> in, JS, CSS, etc.

Correct. The text/gemini media type is being split out into a separate
specification. However, Gemini would be a terribly inefficient way to
distribute pages with linked subresources like inline images, JS, CSS,
etc.

> However, since discussion of Gemini and text/gemini *typically* occurs
> in the same breath, I'll say that the author should have just gone
> ahead and used Markdown as-is instead of taking a subset but defining
> an odd Gopher-imitating rule specifically for links.

Gemini was initially intended to serve Plain Text, like Gopher with the
only improvement being serving UTF-8 text rather than ASCII or regional
code pages. On the development mailing list, I initially pushed for
using a large subset of CommonMark - minus inline HTML and inline
images. Other people argued that the complexity and ambiguity of parsing
Markdown went against the goal of being able to implement a client in a
couple hundred lines of code as a weekend project, something not helped
by the fact that most language libraries for Markdown handling only
provide conversion to HTML, not generating a parse tree.

In the end, the compromise was a text format that could be parsed
line-by-line, with the line type recognized by looking only at the first
3 characters. That's why there's no inline bold or italic formatting,
and why links are not inline. This is quite similar to gophermaps, but
both simpler and more powerful. It's another case where it helps to
remember that Gemini was designed by Gopher users, addressing pain
points in Gopher in a way that is simpler than the WWW, not people
trying mainly to address pain points in the WWW.

--
+-----------------------------------------------------------+
| Jason F. McBrayer jmcbray@carcosa.net |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it. -- Dogen |

Matthew Ernisse <matt@going-flying.com> writes:

> On Wed, 26 Jul 2023 18:14:43 -0000 (UTC), Plain Text wrote:
>> Using client certificates to authenticate as user to some service
>> provided by a capsule seems very elegant to me.
>
> FWIW, this works just fine with HTTPS, most people don't use it but I
> assure you that your favorite web browser almost certainly has a UI
> to specify a client SSL/TLS certificate when requested by the remote
> server. I seem to recall using it for $WORK Intranet sites in the
> early 00's using Netscape.

You're right that HTTPS does provide support for client certificates,
but the mainstream web browsers have relatively recently removed the UI
for creating and using them.

--
+-----------------------------------------------------------+
| Jason F. McBrayer jmcbray@carcosa.net |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it. -- Dogen |

On Mon, 07 Aug 2023 07:46:08 -0400, Jason McBrayer wrote:
> You're right that HTTPS does provide support for client certificates,
> but the mainstream web browsers have relatively recently removed the UI
> for creating and using them.

That's a shame -- though I imagine it was a widely unused feature and
lets face it, properly generating (and safely storing) certificate and
key pairs are difficult tasks likely best left to specalized tools.

--
"The avalanche has started, it is too late for the pebbles to vote."
--Kosh