Uploading Gemini content

Sean Conner sean at conman.org
Sat Jun 13 06:39:26 BST 2020

  Okay, there's quite a few people on this list what would like to see more
content in Gemini.  What I'm proposing is *not* a modification to the Gemini
protocol itself, but it's an adjunct that *could* be implemented [1] to ease
the creation of more Gemini content.  I'm not trying to scare you,
solderpunk, there are others working on this concept, but they aren't on the
mailing list because of technical issues [2].

  Anyway, it's *another* protocol, very similar to Gemini but one that uses
a new URL scheme, to ensure that no one mistakes this for the actual Gemini
protocol.  There are already two variations on this, one by Alex Schroeder
[3] and one by baschdel [4].  The one I've constructed is a mix of the two
but not quite the same.

  I define two new URL schemes---"gemini+put" and "gemini+del".  The first
is to add (or update) a file to a server, while the second exists to delete
a file.  The protocol for uploading a file (C=client, S=server):

C: gemini+put://example.com/path/to/new.txt?mime=text/plain&size=1024 CRLF
S: 1x continue CRLF
C: size bytes of content
S: 31 gemini://example.com/path/to/new.txt CRLF <close>

  The thought process behind this is for the client to send the full path to
the new (or updated) resource.  They query string sends along some critical
information about the upload, the MIME type and the size.  This allows the
server to reject certain types of content or restrict the resources to a
given size. I'm using the query string for this information the other
methods defined by Alex and baschdel stray a bit too far from Gemini (in my
opinion).  I also think it's fine here as I've defined a new URL scheme and
I can say what the sections mean.

  I included the 1x response (input) in order to give the server a chance to
return errors (like unsupported MIME type or size issues) before the client
sends the data.  So the client can expect to see 4x or 5x here (or even
6x---but more on this below).  Once the client sees the 1x response, it can
then proceed with uploading the content.  Upon successfully receiving the
data, the server then responds with a 31 redirection to the new resource on
the server.  I can see an argument for a 20 status, but to me, 31 (a
permanent redirection) seems semantically better for a "successful" upload.

  The protocol to delete a file is not complicated either (C=client,

C: gemini+del://example.com/path/to/old.txt CRLF
S: 52 Gone CRLF <close>

  Again, here a 52 response makes sense as the resource is being
deleted---any other error means an actual error.

  Now obviously this requires some security, so a client certificate giving
authority is required.  The "proof-of-concept" uses the Common Name from the
certificate to control access to the appropriate files.  Assuming user
content is defined by:


a user of the site could generate (and have validated) or be given (by the
admins) a certificate to use to upload content.  The common name could be
the user name so the server will know what area of the filesystem a
certificate is valid for.  

  The idea is for a user to be able to use a Gemini client to not only
browse Gemini content, but *create* and upload new content to a server, from
within the client (a client can shell out to an editor, for instance).  This
should reduce the friction of generating content.

  I do have a "proof-of-concept" mostly finished [5], and if there is enough
interest, I can make it live.  The registration process would probably be
something like:

	1. Generate a CSR (only field required will be CN)
	2. Upload the CSR to a known path (with MIME type application/pkcs10)
	3. Server will then accept the request, sign it, and redirect to the
	   certificate the client can use (MIME type

  And I repeat---this is *NOT* intended to become part of the actual Gemini
protocol, but an adjunct, a separate protocol that is still simple, but
allows data to flow from the client to the server.  And if solderpunk sticks
his fingers in his ears and goes "La la la la la la la" that's fine
too---this is just an idea.


[1]	Because I've implemented it.  It's not live, *yet*.  But my
	"proof-of-concept" does work.

[2]	https://alexschroeder.ch/wiki/2020-06-04_DMARC_an_Mailing_Lists

[3]	https://alexschroeder.ch/wiki/2020-06-05_Gemini_Write

[4]	https://alexschroeder.ch/wiki/Baschdels_spin_on_Gemini_uploading

[5]	All the bits except for certificate generation.  I need to work on
	client certificate verification in GLV-1.12556.

More information about the Gemini mailing list