Thoughts about the Gemini protocol

[Kevin Sangeelee]

Ha, mailing lists have always filled me with dread - unretractable
faux pas being central to my worries!

On Fri, 14 Aug 2020 at 15:28, Matilde Park
<matilde.park at sunshinegardens.org> wrote:
>
> Was responding to OP, sorry. (Getting a handle on mailing lists.)
>
> > On Aug 14, 2020, at 10:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> >
> > I'm not sure if you intended to reply to me, but if so, I think you
> > are indeed mistaken. To be clear, I get Gemini, its simplicity and
> > immediacy are everything. I'd be happy if it stayed exactly as it is.
> >
> > Kevin
> >
> > On Fri, 14 Aug 2020 at 14:35, Matilde Park
> > <matilde.park at sunshinegardens.org> wrote:
> >>
> >> I think this proposal misunderstands the utility of the Gemini protocol, though I may myself be mistaken.
> >>
> >> The web itself shouldn’t have become a widget library, or a set of applications. The DOM is a poor replacement for something like GTK, et al., and HTML/JS/CSS has come pretty far in approximating it to an operating system by punting an operating system level of complexity to the client — thus web browsers are unmaintainable by anyone other than corporations who can build an operating system to a specification.
> >>
> >> In this regard, I think protocols like gemini:// or gopher:// aren’t meant to *supplant* the web, but have a specialised purpose. There can be a very small, human scale specification. Let HTTP do what it’s become specialised to do; and in our own projects, abandon it. In doing so, you can avoid the incentives that brought clearnet where it is now.
> >>
> >>> On Aug 14, 2020, at 9:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I think you're absolutely right that the scope of the web (or more
> >>> specifically, the web browser) has grown to the point that it might
> >>> soon be impractical to make use of it without Google's tech (and you
> >>> only need to look at Android to see how that will play out, and Apple
> >>> are little better). On the other hand, I don't think Gemini is the
> >>> place to address this; as I see it, Gemini stands on its own, with its
> >>> own purpose, which does happen to align with the original purpose of
> >>> the web, and is perhaps why it seems the obvious to modify in the ways
> >>> you suggest (similar types of ideas crossed my mind too).
> >>>
> >>> I personally think that the way to revive the web is to run HTTP on a
> >>> different port so that content can be identified as separate from the
> >>> current web, and where this implies a reduced level of functionality
> >>> (e.g. content that can be rendered by Kristall, or Dillo, or Lynx,
> >>> etc.). I've put a lighttpd server on port 1993 of my Gemini server,
> >>> though I've had no reason to use it yet - I'm free to *not* use any
> >>> web features I don't want to. :-)
> >>>
> >>> Well done on getting your C client running, if you're sharing the
> >>> code, I'd love to check it out!
> >>>
> >>> Kevin
> >>> gemini://gemini.susa.net/
> >>>
> >>> On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
> >>>>
> >>>> Hello everyone,
> >>>>
> >>>> The recent news about the layoffs at Mozilla have left me wondering as
> >>>> to whether the modern web has become too complex. I've heard people
> >>>> discuss the Gemini protocol as a simplified alternative that is way
> >>>> easier to work with. After checking it out (and even trying to write a
> >>>> small experimental client in C, which thanks to libtls, ended up way
> >>>> easier than I thought), it seems to be a really promising idea.
> >>>>
> >>>> I was thinking about an idea similar to Gemini that could work as a
> >>>> protocol for not just websites, but also simple and functional web
> >>>> applications as well that could, to a reasonable extent, look and work
> >>>> well on lots of different devices (desktops, smartphones, feature
> >>>> phones, text-mode interfaces). After seeing how the Gemini protocol
> >>>> works, it seems to me that a lot of these ideas could be implemented in
> >>>> a backwards-compatible way or with minimal modifications to the
> >>>> protocol.
> >>>>
> >>>> 1. Basic form inputs / "widgets"
> >>>>
> >>>> In addition to an "INPUT" response that only requests a line of text and
> >>>> returns the question as a single line in the <META> field, some sort of
> >>>> "extended input" could be useful. It could still be restricted to a
> >>>> single query, but it could provide software-interpretable hints as to
> >>>> what kind of input is preferable.
> >>>>
> >>>> For example, a "check" input could provide a numbered list of options
> >>>> and then ask the user to submit a query consisting a list of the
> >>>> numbered items the user wants to select (or 0 if none). A more advanced
> >>>> client program would then display the entire request as a series of
> >>>> checkboxes or switches that the user can toggle. A "radio" or "button"
> >>>> input could demand a single number, and the client would display the
> >>>> items as a list of radio switches or buttons, of which only one can be
> >>>> selected.
> >>>>
> >>>> (I can imagine the description of the inputs either being part of the
> >>>> <META> field, part of the previous page's text or maybe an "extended
> >>>> input" could have its own response body that they're written in.)
> >>>>
> >>>> Or a "date" input could say that it expects a date in the YYYY-MM-DD
> >>>> format, but an advanced client could provide the user with a date picker
> >>>> instead.
> >>>>
> >>>> Either way, the general idea is that a simple client could just ask the
> >>>> user to write the query as a line of text.
> >>>>
> >>>> 2. Continuous connections
> >>>>
> >>>> A user might want to not just give commands to a service, but also to
> >>>> expect it to provide a continuous stream of information over a long
> >>>> term. Most modern web pages use scripting to accomplish something like
> >>>> that (and most web-browsers wait for a page to finish loading before
> >>>> displaying it), but a minimal version of this seems achievable without
> >>>> it.
> >>>>
> >>>> An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
> >>>> or mime-type (say, "text/gemini-continuous") would indicate that the
> >>>> server will not give the entire response at once and then immediately
> >>>> close the connection, but instead the connection will continue for a
> >>>> long time, and instead of waiting for the entire text to be received,
> >>>> the client should look for whenever a complete line arrives and print
> >>>> that line.
> >>>>
> >>>> The client could then use that connection to receive updates on the
> >>>> request, until either the client or the server actually decides to close
> >>>> the connection or it gets closed by some other means.
> >>>>
> >>>> 3. Append mode
> >>>>
> >>>> This is just a little extra feature, but the idea is that a page
> >>>> (probably also via mime-type, like "text/gemini-append", or an
> >>>> additional parameter, like "text/gemini; append") could indicate that
> >>>> its contents should, if possible, be added at the end of the previous
> >>>> page, rather than replacing it entirely.
> >>>>
> >>>> ---
> >>>>
> >>>> I would like to hear your opinions as to whether these ideas could, or
> >>>> should, be added to the Gemini protocol, and in which specific ways if
> >>>> so. Thank you all very much.
> >>
>