💾 Archived View for rawtext.club › ~sloum › geminilist › 001632.gmi captured on 2020-10-31 at 02:25:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sat Jun 13 21:56:35 BST 2020
- - - - - - - - - - - - - - - - - - -
A couple of thoughts on this new line of discussion:
1. I am very grateful that people have made a point of defining this asseparate "companion" protocol rather than asking for it as part of thecore Gemini protocol, to give me a bit of breathing room. I *do* likethe idea of naming it titan://...
2. At this point I can only laugh at the completeness with which usingURIs as requests has backfired on me. First the userinfo auto cookiedebacle and now, hah, the scheme has proven its ability to function asa vehicle for different request methods. Yes, the '+' character isvalid in a URI scheme. So, why not gemini+HEAD://, gemini+POST://,gemini+PUT://.... Moral of the story: everything is always extensibleif you try hard enough. Corollary: Gopher has remained largelyunextended for so long for non-technical, presumably cultural reasons.There may be great wisdom to be found in understanding why.
3. Dear God, when/where/how does it stop?! This was supposed to be asimple, humble, protocol of limited scope! But...
4. ...I totally "get it", with the ability to edit Gemini resources fromwithin the client. Compared to the current situation where publishingin Geminispace requires using scp, (s)ftp, rsync, git or whatever, thisfeature would make the protocol accessible to literally several ordersof magnitude more people. The decision to let this happen or to crushit in the name of simplicity and minimalism could have tremendousconsequences for the eventual destiny of Gemini. It's exciting stuff,and I don't want to exclude non-technical people from using what we'vebuilt. But...
5. ...I'm wary that facilitating "user friendly" Gemini hosts whichanybody can post to using a client carries a very real risk of fosteringa culture of dependency where people don't know how to do anything notoffered as a feature by their provider, who has the ability to change,remove, or charge for those featurs, and also of pushing us toward amore centralised Geminispace where large numbers of users congregate ona small number of servers which make themselves especially appealing tonon-technical users. These servers could easily become littlesemi-closed gardens with internal-only comment notification facilitiesand other such niceties which work much more smoothly than the variousdecntralised solutions people have already been talking about. Theymight not, but the risk is there: we might just end up creating newversions of LiveJournal, Wordpress, Blogspot, etc, etc.
6. Does anybody else feel like we are just instinctively re-implementingthe familiar history of the web without much caution or criticalthought?
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 futurewhere IPv6 or something else has provided us all with abundantpublically reachable addresses, the obvious and elegant way for aclient to upload to a Gemini "server" is actually to just host theresource itself, on a random, one-use-only URL, and then send that URLas a query to a well-known uploading endpoint on the other end,whereupon the "server" briefly becomes a client and fetches the resourcein the usual way. Nothing extra needed in the protocol at all!
Cheers,Solderpunk