gemini+submit:// (was Re: Uploading Gemini content)
luke at marmaladefoo.com
Sat Jun 13 14:06:48 BST 2020
I've been thinking some more about this self-editing wiki concept, which
seems a great application to support writers of Gemini content. I think
there is an opportunity for a very simple addition to Gemini that would
support client based content submission.
The mental model is quite simple - imagine a simple web page, having a
single text area and a single submit button. The user can edit the text
and submit the content. The client knows where to send the content (form
attribute) and how to send it (HTTP protocol using POST).
Exactly what the name for this doesnt really matter, and it will need to
integrate with the authentication/certificates mechanisms we already are
Essentially there are a number of new elements
1. New scheme extending gemini, only for those that want to. This is not
gemini, but something else. Whether it gets considered for gemini is a
2. An extended client behaviour working with the preformatted text
regions having suitable markers to be defined
3. A simple text submit protocol (text/plain only, UTF-8 only)
The elements could look like this
1. The scheme name is gemini+submit:// or something, doesnt really
matter, but is distinct from gemini://.
2. Using the preformatted regions to specify the URL end point to post
to. Only end points having gemini+submit:// as the scheme would have an
active behaviour. This is done in a backwards compatible way so simpler
clients just render the content as preformatted text
Note we use 4 back ticks to convey that the content may be edited and
submitted. There could be some other option to indicate this, the syntax
marker is not significant, can be changed to ```! or something else.
This gracefully degrades and is valid text/gemini
```` (could be 3 or 4 doesnt really matter)
the 4 back ticks mean existing clients will just show the text.
The URI will probably contain information for the server to know where
to put the content such as:
3. The client allows the user to edit the content and then "submit"
(button or whatever) the content to the end point as follows:
<client sends the byte content>
<client closes connection>
Only text/plain is ever sent so we don't need to specify mime type.
Simple and restricted.
Only UTF is ever sent, so we dont need to specify it. Simple and restricted.
There is only ever one "block" of text submitted, which is the content
of the preformatted area (no multi-field forms).
The end point on the server knows when content has arrived as the
content length is pre-notified in the header, replies with redirect to
success page probably.
server may also respond requesting input,certificates
on the server, the end point might be inside the server or could be a
CGI or similar application that might get the content via stdin (as per
POST for HTTP)
It would be nice to adopt a common scheme for this together with
gemini+put:// (for arbitrary binary upload) and gemini+delete://
suggestions suggested earlier on this thread. For example to integrate
certificates, success or failure etc.
Potentially this scheme can be used to edit simple text content of a
number of back end applications.
There are no changes need to any client or server that is not interested
to implement this.
I think this has a similar simplicity to the spirit of Gemini and does
not open huge doors for a horse and cart to come through.
More information about the Gemini