Thoughts about the Gemini protocol

[Kevin Sangeelee]

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