💾 Archived View for rawtext.club › ~sloum › geminilist › 001638.gmi captured on 2020-09-24 at 01:44:58. Gemini links have been rewritten to link to archived 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 likedit. 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 solvetheir problems using tools at hand, even if they may not be the best toolsto 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 URLswith query strings even though that's not allowed). I think the otherreason (besides cultural) is that it died *quickly* (for the most part) inthe mid-90s (when the UoM wanted to charge royalties for use of the protocolwhen HTTP was free). It limped along for *years* until maybe 2010 whenthere was a newed interest, and it's not like people are refusing to useUTF-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 "developmentin the browser via HTTP only" since 1996, but as far as I know, no currentbrowser (or even old ones from the time) ever did this. I know programslike DreamWeaver [2] could upload documents to a server, but it did so overFTP, not the web.
Another aspect is that it wasn't apparent *how* to support methods likePUT or DELETE in a general purpose web server, and it took several years forApache (for example) to even provide a way to do this---either via customApache modules [3] or (eventually) through a CGI script. In any case, itrequired special configuration on the server side of things, and for masshosting ... you ain't gonna get that. I can, but that's because I'm insaneenough to run my own web server (and email server, and gopher server, andgemini 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 initialdevelopment of Gemini to push for more web-like features. And this proposalwoudn't even have come to light if it weren't for Alex Schroeder working onthis 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