gemini://soviet.circumlunar.space/oak/mailinglist/10.gmi

Date: Wed, 27 Jan 2021 17:19:59 -0500

> Having more complex forms is a temptation to implement applications on

> Gemini, rather than using pairings of protocol+client that are more

> appropriate (e.g. using NNTP for a message board).

Charlie Stanton <charlie at shtanton.com> wrote:

> I agree with this completely. I think Gemini should be a protocol for

> viewing content only. I missed all the discussion around inimeg, titan

> etc. at the time but I feel similarly about those.

> I think a different protocol for filling out forms makes a lot more

> sense, and we can work on having gemini clients and form clients play

> nicely together so the user experience doesn't suffer from using a

> different program to fill out a form.

> Adding forms would take us wayyyyy too close to the web in my opinion.

tl;dr: Gemini can already emulate forms. We just need a spec language

clarification in Section 3.2.1 1x (INPUT) from Solderpunk and for

client authors to update their software accordingly. I illustrate

both points (and provide code) below.

I appreciate the generally conservative nature of the Gemini community

when it comes to extending the Gemini and Gemtext specifications. As a

server author, this certainly keeps my life easier.

However, I'd like to go on record here to say that interactive capsules

are not something that worries me. There are already quite a few of them

out there in Geminispace (hello Astrobotany!), and I'd like to continue

to see this medium grow and thrive in our little corner of the internet.

I don't think form-like data submission should be seen as an evil. It

allows us to implement a wide variety of CGI-style applications that do

all their computing on the server side (often through some script

extension mechanism). This keeps our servers and clients simple,

empowers content authors to build cool things, and still keeps us nicely

insulated from "The Javascript Trap" since our Gemini clients never

download and run any client-side code.

Over the months that I have followed this mailing list, I've seen

broadly two categories of proposals around extending Gemini's simple

1. Ways to submit multiple pieces of information to a server at once.

2. Ways to upload files to a server.

Both proposals are pretty self-explanatory since they extend the

possible functionality of interactive Gemini capsules without breaking

any of our privacy or security guarantees. However, option 1 puts an

additional burden on client authors, and option 2 puts an additional

burden on both client and server authors.

Some members of our community have suggested that these features aren't

worth the extra effort. Others have argued in favor of one or both of

them, and a brave few have gone off and created their own sister

protocols to try and implement Gemini-like systems that also support

some variant of these two data upload options (e.g., Titan, Dioscuri,

>From a personal standpoint (and I can only speak for myself here

obviously), I wouldn't mind one or more form types being added to

Gemtext (option 1 above) as it would reduce the total number of

round-trip network requests between client and server to submit multiple

pieces of information (and I have quite a slow satellite internet

connection, so this matters to me).

However, even without (a very unlikely) form enhancement to Solderpunk's

Gemtext spec, I'd like to remind folks that we actually do (or at least

we should) already have the ability to emulate forms in our Gemini

Assuming we are currently browsing a page at

gemini://awesome.capsule.net/form, this dynamic Gemtext page could

include forms as follows:

Here, my Gemtext is a template string, which I process in a context in

which $SESSION, $NAME, $PASSWORD, $SMOG, and $PLANT are defined (or

default to empty strings). When the page first loads, we create a new

$SESSION value in our CGI script and insert it into the links to

preserve state across requests until we restart the server or the user

(Obviously, a more robust state management mechanism could be achieved

with client certs and a DB, but I just mean to show a very simple

Here would be the server-side responses for each of those links:

NAME: 10 Enter your name\r\n

PASSWORD: 11 Enter password\r\n

SMOG: 10 Choose one of [Yes|No]\r\n

PLANT: 10 Choose one of [Ficus|Baobob|Pachypodium|Moss]\r\n

For the boolean choice (SMOG) and the multiple choice (PLANT) inputs,

you could, of course, perform input validation and re-prompt if

necessary. You could also simply include one link per choice in your

form template instead of using a 10 INPUT response.

The intention of this example is that the clients would produce requests

of this form after each input prompt:

where $SESSION is whatever value was generated by the CGI script on the

With this information in the query params, it would be easy to store a

lookup table in the CGI script that mapped session -> field -> value,

and these values can then be easily inserted into the original Gemtext

template form above (see Section 3.1) in response to these requests.

The form?$SESSION&submit link can then trigger the server to validate

that all of the required form fields have been filled in correctly and

perform whatever next step operation you want.

In addition, as I mentioned several months ago on this list, you could

perform file "uploads" by having one of the input links prompt for a URL

to a file. Then the server could download that file and store it in your

session (or account if you're using client certs and a DB).

While this example creates more back-and-forth requests than a proper

client-side form would generate, I hope it demonstrates that Gemini and

Gemtext in their current incarnations are already sufficiently complete

to build interactive CGI applications with them today.

The only problem I'm running into here is that the various Gemini

clients I've tested (elpher, bombadillo, kristall) don't actually append

a user's input as an additional parameter to an existing query string if

one is present. Instead, bombadillo and kristall just overwrite the

existing query string and only return ?$NEW_INPUT. Elpher, on the other

hand, just creates invalid URLs by simply appending ?$NEW_INPUT to

whatever is already in the URL (e.g.,

gemini://awesome.capsule.net/form?$SESSION&smog?yes. Neither of these

behaviors do what I'd want or expect here.

I think the culprit then is probably Gemini Protocol Specification

section 3.2.1 1x (INPUT):

As far as I can tell, the fix here is for Solderpunk to update the text

in section 3.2.1 to indicate that if a query string is already part of

the request leading to an INPUT response, then the user's input should

be appended (using &) to the existing query string rather than replacing

Otherwise, we really have no way to input more than one query param

(with &) other than asking the user to type it directly into the INPUT

prompt (e.g., cat&dog&pig). I'm hoping this isn't the spec's intention

here and that we just have a case of ambiguous wording that has led some

client authors to create divergent (or broken) implementations.

Okay, that was a LONG message, but I hope I've communicated my points

clearly. Thanks to all who read this far, and thanks to everyone for

making Gemini such an active and engaging community!

I've attached a short (47 line) CGI script (for Space Age) that

implements the dynamic form example described in this email. If clients

would append user input params (with &) to existing query strings rather

than replace them, it should work perfectly. Until then, it will just

have to feel a bit sad and dejected.

Whose client is going to make it work first! I wait eagerly with bated

-------------- next part --------------

An embedded and charset-unspecified text was scrubbed...

URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210127/4d28aea6/attachment.ksh>

-------------- next part --------------

Use `gpg --search-keys lambdatronic' to find me

Protect yourself from surveillance: https://emailselfdefense.fsf.org

=======================================================================

() ascii ribbon campaign - against html e-mail

/\ www.asciiribbon.org - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.

See http://www.gnu.org/philosophy/no-word-attachments.html

Date: Fri, 29 Jan 2021 13:05:31 +0100

Gary Johnson <lambdatronic at disroot.org> wrote

> => form?$SESSION&name Name: $NAME

> => form?$SESSION&password Password: $PASSWORD

> => form?$SESSION&smog SMOG is great: $SMOG

> => form?$SESSION&plant Best Astrobotany Plant: $PLANT

> => form?$SESSION&submit Submit Answers

(Obviously, a more robust state management mechanism could be achieved

> with client certs and a DB, but I just mean to show a very simple

Yes, if the client supports client certificates, we can skip sending

$SESSION and use the regular inputs:

> The intention of this example is that the clients would produce requests

> of this form after each input prompt:

> => gemini://awesome.capsule.net/form?$SESSION&name&Gary%20Johnson

> => gemini://awesome.capsule.net/form?$SESSION&password&secret

> => gemini://awesome.capsule.net/form?$SESSION&smog&yes

> => gemini://awesome.capsule.net/form?$SESSION&plant&Ficus

> where $SESSION is whatever value was generated by the CGI script on the

I do not understand this example.

When using regular inputs, the client will send these requests:

gemini://awesome.capsule.net/form/name?Gary%Johnson

gemini://awesome.capsule.net/form/password?secret

gemini://awesome.capsule.net/form/smog?yes

gemini://awesome.capsule.net/form/plant?Ficus

gemini://awesome.capsule.net/form/submit

(No "?" on "submit" since it's just telling the server that we're done.)

What is the benefit of doing it your way?

> With this information in the query params, it would be easy to store a

> lookup table in the CGI script that mapped session -> field -> value,

> and these values can then be easily inserted into the original Gemtext

> template form above (see Section 3.1) in response to these requests.

If you format the URLs like this:

gemini://$HOST/path/to/script/$FIELD?$VALUE

...then $FIELD should show up as PATH_INFO (probably with a leading "/")

and $VALUE as QUERY_STRING.

The only problem I'm running into here is that the various Gemini

clients I've tested (elpher, bombadillo, kristall) don't actually append

> a user's input as an additional parameter to an existing query string if

> one is present. Instead, bombadillo and kristall just overwrite the

> existing query string and only return ?$NEW_INPUT. Elpher, on the other

> hand, just creates invalid URLs by simply appending ?$NEW_INPUT to

> whatever is already in the URL (e.g.,

> gemini://awesome.capsule.net/form?$SESSION&smog?yes. Neither of these

> behaviors do what I'd want or expect here.

Elpher is doing something weird here but the others are handling inputs as

> I think the culprit then is probably Gemini Protocol Specification

> section 3.2.1 1x (INPUT):

> As far as I can tell, the fix here is for Solderpunk to update the text

> in section 3.2.1 to indicate that if a query string is already part of

> the request leading to an INPUT response, then the user's input should

> be appended (using &) to the existing query string rather than replacing

> it wholesale (using ?).

This is not a necessary spec change.

Otherwise, we really have no way to input more than one query param

> (with &) other than asking the user to type it directly into the INPUT

> prompt (e.g., cat&dog&pig).

The responsibility for collecting parameters fall on the server, not on the

client. The only thing the client needs to do is sending one query for each

I'm hoping this isn't the spec's intention

> here and that we just have a case of ambiguous wording that has led some

> client authors to create divergent (or broken) implementations

Sorry to disappoint you. I suggest leaving the ampersands to the web

I've attached a short (47 line) CGI script (for Space Age) that

> implements the dynamic form example described in this email.

Thank you for providing example code and I'm sorry for not doing the same.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210129/c5136798/attachment.htm>

Date: Sat, 30 Jan 2021 15:54:39 -0500

> ## Section 3.3: (DESIRED) Client-side Requests

>> The intention of this example is that the clients would produce requests

>> of this form after each input prompt:

>> => gemini://awesome.capsule.net/form?$SESSION&name&Gary%20Johnson

>> => gemini://awesome.capsule.net/form?$SESSION&password&secret

>> => gemini://awesome.capsule.net/form?$SESSION&smog&yes

>> => gemini://awesome.capsule.net/form?$SESSION&plant&Ficus

>> where $SESSION is whatever value was generated by the CGI script on the

> I do not understand this example.

> When using regular inputs, the client will send these requests:

> gemini://awesome.capsule.net/form/name?Gary%Johnson

> gemini://awesome.capsule.net/form/password?secret

> gemini://awesome.capsule.net/form/smog?yes

> gemini://awesome.capsule.net/form/plant?Ficus

> gemini://awesome.capsule.net/form/submit

> (No "?" on "submit" since it's just telling the server that we're done.)

> What is the benefit of doing it your way?

Thanks for taking the time to reply to my message. I'll try to clarify

The issue I'm raising is that there appears to be no way to pass more

than one piece of information at a time in our query strings. This has a

very significant impact on any writers of CGI scripts, which is how many

Gemini servers allow users to add dynamic pages to their capsules.

Because each CGI script is available at a particular file path and

therefore additional path segments can't be used to pass information to

them. They have to get their inputs from the query string.

This is a script. It probably returns a 20 response:

If I want to fill in a name field on that page, I might provide a link

This calls the CGI script with a query parameter. Great! The script can

use "name" to look up the appropriate response. Here it is:

10 Please enter your name\r\n

However, when the user fills in their name, the browser will now send

this request to the server:

There is no way for the CGI script to know that this is a name value and

not the value for any other form field on the page.

And therein lies the rub. If the only way to associate input values with

the variables they represent is with path segments, then CGI scripts

simply can't ever use more than one input field per page. Even then, if

the query string used to trigger a 10 INPUT response is typed by the

user (into the totally free form text field they are presented), then

the server will continue to respond with yet another 10 INPUT response.

This would make a form with N fields require N+1 separate CGI scripts,

all chained together via links that represent the directory structure

into which they are installed.

This is an absolute nightmare scenario for programming anything that

wants to accept user inputs.

So what does this mean for Geminispace?

It means essentially that CGI scripts are currently second-class

citizens, and the only people who can write dynamic capsules are server

authors (or people willing to hack on server code). This is because

encoding information using path segments requires injecting custom

routing table code into the server's request handler.

As a server author, I am capable of creating a custom fork of my server

with a new routing table for each dynamic capsule I want to build.

However, I suspect the majority of Gemini users are not going to have

both the skill and willingness to engage in this level of coding on

That is why I and many other authors have added support for CGI scripts

to our servers. But under the "only one piece of information in the

query string" paradigm, these scripts are currently rather handicapped

when it comes to accepting user input.

Hopefully, I've made the technical merits of my case clear here.

> ## Section 4.2: Append Don't Replace!

>> As far as I can tell, the fix here is for Solderpunk to update the text

>> in section 3.2.1 to indicate that if a query string is already part of

>> the request leading to an INPUT response, then the user's input should

>> be appended (using &) to the existing query string rather than replacing

>> it wholesale (using ?).

> This is not a necessary spec change.

Yes, it really is if anyone other than server authors is ever going to

be able to write their own dynamic pages.

> Otherwise, we really have no way to input more than one query param

>> (with &) other than asking the user to type it directly into the INPUT

>> prompt (e.g., cat&dog&pig).

> The responsibility for collecting parameters fall on the server, not on the

> client. The only thing the client needs to do is sending one query for each

Again, see above. A single query value cannot be associated with its

variable without adding a custom routing table to the server to enable

the parsing of path segment data as additional inputs.

> I'm hoping this isn't the spec's intention

>> here and that we just have a case of ambiguous wording that has led some

>> client authors to create divergent (or broken) implementations

> Sorry to disappoint you. I suggest leaving the ampersands to the web

I'm afraid we disagree here.

> Thank you for providing example code and I'm sorry for not doing the same.

If you can write a CGI script that can correctly associate INPUT

responses with their intended variables, please share it. I suspect it

would be quite educational.

Use `gpg --search-keys lambdatronic' to find me

Protect yourself from surveillance: https://emailselfdefense.fsf.org

=======================================================================

() ascii ribbon campaign - against html e-mail

/\ www.asciiribbon.org - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.

See http://www.gnu.org/philosophy/no-word-attachments.html

Date: Sat, 30 Jan 2021 22:19:25 +0000

This is going to be weird, because I disagree with almost everything you've said except that appending the query string should be guaranteed. I hope this is helpful

January 30, 2021 1:54 PM, "Gary Johnson" <lambdatronic at disroot.org> wrote:

> The issue I'm raising is that there appears to be no way to pass more

> than one piece of information at a time in our query strings. This has a

> very significant impact on any writers of CGI scripts, which is how many

> Gemini servers allow users to add dynamic pages to their capsules.

> Because each CGI script is available at a particular file path and

> therefore additional path segments can't be used to pass information to

> them. They have to get their inputs from the query string.

%< ------------------------------

> This would make a form with N fields require N+1 separate CGI scripts,

> all chained together via links that represent the directory structure

> into which they are installed.

> This is an absolute nightmare scenario for programming anything that

> wants to accept user inputs.

Well, you *could* pass extra path info to the script... So, the script at cgi-bin/index.cgi handles all cgi-bin/* and treats the path after cgi-bin as positional arguments

> So what does this mean for Geminispace?

> It means essentially that CGI scripts are currently second-class

> citizens, and the only people who can write dynamic capsules are server

> authors (or people willing to hack on server code). This is because

> encoding information using path segments requires injecting custom

> routing table code into the server's request handler.

CGI scripts *are* second class citizens in Gemini, but it's because the UX and dev-op experience of line based input is terrible. The fact that a static routing table is more performant and has a better security profile than parsing the path info dynamically is less relevant than the fact that this is a line based protocol

%< ------------------------------

>> ## Section 4.2: Append Don't Replace!

>>> As far as I can tell, the fix here is for Solderpunk to update the text

>>> in section 3.2.1 to indicate that if a query string is already part of

>>> the request leading to an INPUT response, then the user's input should

>>> be appended (using &) to the existing query string rather than replacing

>>> it wholesale (using ?).

>> This is not a necessary spec change.

> Yes, it really is if anyone other than server authors is ever going to

> be able to write their own dynamic pages.

Now, "Append, don't replace," is a reasonable expectation to make of clients and it's still useful for the devops situation, even if it's not *strictly* necessary

%< ------------------------------

> If you can write a CGI script that can correctly associate INPUT

> responses with their intended variables, please share it. I suspect it

> would be quite educational.

The two alternatives to requiring clients to preserve collected state in the query parameter are to save state in the CGI script or to pass positional arguments via the path. I think append is reasonable. It also preserves principle of least surprise and other desirable qualities

CGI *is* going to be second class in Gemini as long as forms aren't an option, but that's a consequence of the decision to support line-based clients. Appending the query doesn't do violence to that design

Date: Sat, 30 Jan 2021 18:59:47 -0500

It was thus said that the Great Gary Johnson once stated: