Thoughts about the Gemini protocol

[Kevin Sangeelee]

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.