Proposal: Simple structured form specification

Johann Galle johann at
Wed Jan 27 18:52:38 GMT 2021

I think this should have a [TECH] tag? [1]

I am quite firmly on the "Gemini does not need forms" side. At least as far as implementing additional syntax in clients. For some clients it might be a big leap to have to implement this, especially considering you can already build forms in Gemini, you just have to get a bit creative and it does not require any new syntax or behaviour on the client side. And thus no additional specification. But again: One should think twice if this really has to be implemented using Gemini and not another, more suited protocol.

The basic idea is the following: Each form field is presented on a separate "page" and the server keeps track of where the client is in the form. Ideally the URL (URI/IRI?) contains all the data necessary, thus "saving" the data on the client so it might be continued at a later date. If the amount of data expected is larger than would fit in the URL, server side state with client certificates would be an alternative.

Now to the different types of input fields. I assume the form's base is gemini:// which might display some information about the form and the first input field.

On 27.01.2021 18:37, me at wrote among other things:
 > # binary
 > Binary options are best known as checkboxes on the web. They're simple on/off toggles. How they are displayed is up to the client

A check box can be simply implemented with two links for yes and no like this for example:
Does Gemini need forms?
=> 0/ No, it does not.
=> 1/ Yes, it does.

These two links would then direct the client to either <gemini://> or <gemini://> respectively. Now the server would have to understand that this still belongs to the form and it should serve the next input field page. In this example I just put each input in a path segment as that is the first thing I came up with. You could of course put this in the query, separate it with spaces, commas semicolons or something completely different.

A nice side effect of doing it this way is that you could in theory build this from a static site server by creating respectively named directories and index.gmi files (or whatever your server happens to use).

 > # text
 > The bulk of data that we could ever ask for is just 'text'.

We already have this (and passwords too!) with status codes 10 and 11. So when you go to either of the URLs in the example above, the server will have to respond with that status code. Upon receiving the data it might redirect the client so that the URL holds some representation of the data, say for example to <gemini://>.

 > Differentiating between "tel" "num" and "text" should be done server-side, as these are all still just text fields.

I completely agree.

 > "password" is deliberately not supported -- this is why gemini has client certs.

Odd choice considering Gemini already has support for this.

 > If an input should be multi-line, then the following could be used: [...]

That is not something that could be implemented by using Gemini this way [2], but if you want to write big amounts of text, you should really use something else, e.g. file upload (ftp) or maybe email, irc, xmpp, nntp, etc.

 > # choice
 > Choice is ultimately optional, IMO. This provides closed-ended responses for a user. Again, the idea of "radio" vs. "dropdown" vs. anything else does not matter, as those are entirely client-side decisions. What's important is that the user is only able to select one response.
 > <= choice Which of these protocols are we using?
 > <= choice gemini
 > <= choice gopher
 > <= choice HTTP

This could be implemented just like a checkbox, just with more options. Coincidentally the syntax is very similar to the one proposed.
Which of these protocols are we using?
=> gemini/ gemini
=> gopher/ gopher
=> http/ HTTP

 > # submit
 > Finally, submit. This one's easy:

... because it is not necessary. The server will just show you the result or take the respective action after the last form field is filled. Maybe a final checkbox of "Are you sure" would be nice to let the user know that this will result in some action.

 > # Putting it all together
 > The last part is how it's passed. As mentioned at the beginning, I think (were gemini to support this, which I don't think it should) that form inputs are sent /positional/, not named. This is a requirement to reduce the chance of hitting the url limit.

And as I said above, you can pass these however you like, although I would guess using the path segment approach would be the easiest and best supported. If I recall correctly there were different opinions voiced about carrying on a query in a redirect. So who knows what some clients might do if the data is all stored in the query and a user decides to go to the next form field.

 > and that's it!

... we do not need an additional specification for this. If you insist on implementing forms in Gemini, you already can - it just requires you to think a bit, and the solution might addmittedly be a bit clunky. But that's because Gemini is not meant for doing forms!

I hope this was not too bad of a rant but actually helpful.



[2] Maybe you could have the users type in some escaped line feeds, but the specification says: "The requested resource accepts *a line* of textual user input." (§ 3.2.1, emphasis mine)
You can verify the digital signature on this email with the public key available through web key discovery. Try e.g. `gpg --locate-keys`...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Gemini mailing list