gemini+submit:// (was Re: Uploading Gemini content)

Sean Conner sean at conman.org
Sat Jun 13 23:11:04 BST 2020


It was thus said that the Great solderpunk once stated:
> A couple of thoughts on this new line of discussion:
> 
> 1. I am very grateful that people have made a point of defining this as
> separate "companion" protocol rather than asking for it as part of the
> core Gemini protocol, to give me a bit of breathing room.  I *do* like
> the idea of naming it titan://...

  Fair enough.  titan: it is.

> 2. At this point I can only laugh at the completeness with which using
> URIs as requests has backfired on me.  First the userinfo auto cookie
> debacle and now, hah, the scheme has proven its ability to function as
> a vehicle for different request methods.  Yes, the '+' character is
> valid in a URI scheme.  So, why not gemini+HEAD://, gemini+POST://,
> gemini+PUT://....  

  Yes, the more I thought about gemini+put:, gemini+del:, the less I liked
it.  And no, the extensibility did not escape me as I was working on this.

  Another way of looking at this is the lengths people will go to to solve
their problems using tools at hand, even if they may not be the best tools
to use to solve the issue.  See Raymond Chen's blog "The Old New Thing" [1]
where he describes some of the crazy things Windows programmers have done.

> Moral of the story: everything is always extensible if you try hard
> enough. Corollary: Gopher has remained largely unextended for so long for
> non-technical, presumably cultural reasons. There may be great wisdom to
> be found in understanding why.

  Gopher has its own URL scheme, which doesn't include:

	* userinfo
	* query string
	* fragments

  That hasn't stopped people from misusing it though (I've seen gopher URLs
with query strings even though that's not allowed).  I think the other
reason (besides cultural) is that it died *quickly* (for the most part) in
the mid-90s (when the UoM wanted to charge royalties for use of the protocol
when HTTP was free).  It limped along for *years* until maybe 2010 when
there was a newed interest, and it's not like people are refusing to use
UTF-8 or non-standard selector types because they're not allowed to ...

> 3. Dear God, when/where/how does it stop?!  This was supposed to be a
> simple, humble, protocol of limited scope!  But...
> 
> 4. ...I totally "get it", with the ability to edit Gemini resources from
> within the client.  Compared to the current situation where publishing
> in Geminispace requires using scp, (s)ftp, rsync, git or whatever, this
> feature would make the protocol accessible to literally several orders
> of magnitude more people.  The decision to let this happen or to crush
> it in the name of simplicity and minimalism could have tremendous
> consequences for the eventual destiny of Gemini.  It's exciting stuff,
> and I don't want to exclude non-technical people from using what we've
> built.  But...
> 
> 5. ...I'm wary that facilitating "user friendly" Gemini hosts which
> anybody can post to using a client carries a very real risk of fostering
> a culture of dependency where people don't know how to do anything not
> offered as a feature by their provider, who has the ability to change,
> remove, or charge for those featurs, and also of pushing us toward a
> more centralised Geminispace where large numbers of users congregate on
> a small number of servers which make themselves especially appealing to
> non-technical users.  These servers could easily become little
> semi-closed gardens with internal-only comment notification facilities
> and other such niceties which work much more smoothly than the various
> decntralised solutions people have already been talking about.  They
> might not, but the risk is there: we might just end up creating new
> versions of LiveJournal, Wordpress, Blogspot, etc, etc.

  As I said, HTTP has had all the features required to support "development
in the browser via HTTP only" since 1996, but as far as I know, no current
browser (or even old ones from the time) ever did this.  I know programs
like DreamWeaver [2] could upload documents to a server, but it did so over
FTP, not the web.

  Another aspect is that it wasn't apparent *how* to support methods like
PUT or DELETE in a general purpose web server, and it took several years for
Apache (for example) to even provide a way to do this---either via custom
Apache modules [3] or (eventually) through a CGI script.  In any case, it
required special configuration on the server side of things, and for mass
hosting ... you ain't gonna get that.  I can, but that's because I'm insane
enough to run my own web server (and email server, and gopher server, and
gemini server ... ).

> 6. Does anybody else feel like we are just instinctively re-implementing
> the familiar history of the web without much caution or critical
> thought?

  Believe me, I had actively surpress thoughts during the initial
development of Gemini to push for more web-like features.  And this proposal
woudn't even have come to light if it weren't for Alex Schroeder working on
this because he likes wikis so much (also, see my response for point 2).

> 7. It's of no practical use today, here and now, for "everyday users",
> but I just want to get it on the record that in a hypothetical future
> where IPv6 or something else has provided us all with abundant
> publically reachable addresses, the obvious and elegant way for a
> client to upload to a Gemini "server" is actually to just host the
> resource itself, on a random, one-use-only URL, and then send that URL
> as a query to a well-known uploading endpoint on the other end,
> whereupon the "server" briefly becomes a client and fetches the resource
> in the usual way.  Nothing extra needed in the protocol at all!

  I responsed to this in my previous email.

  -spc

[1]	https://devblogs.microsoft.com/oldnewthing/

[2]	An HTML editor from the mid to late 90s.

[3]	Not easy to do.  I did write an Apache module [4] twenty years ago
	and I find it easier to maintain a instance of Apache 1.3 to run it,
	than to try to adapt the code to Apache 2.4.  Maybe one of these
	days I'll get a round tuit.

[4]	https://github.com/spc476/mod_litbook


More information about the Gemini mailing list