💾 Archived View for samsai.eu › gemlog › 2020-11-05-post-in-gemini.gemini captured on 2023-01-29 at 02:35:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-11-07)
-=-=-=-=-=-=-
I read ew0k's post about the addition of a POST request to Gemini and I figured I'd want to hop onto this discourse because it's something that I've been wondering as well.
I've personally also been a bit conflicted on this topic because I also figured that a POST request would probably be important to add. I have this idea for creating a kind of a Talos Principle inspired forum/message board software on Gemini and only using GET requests definitely creates limitations. For example, basically the only way to ask for more complex input is via multiple input lines, which isn't particularly great in terms of UX.
However, I think I'm starting to lean on the more conservative side here. POST requests would naturally require us to have forms, which means that gemtext would need to be able to express these forms. The likely outcome would be that gemtext would become significantly harder to parse, unless forms were defined purely as input fields, each on its own line and a POST request would simply send the data from all fields in one go. In either case, some additional complexity would result from such a feature, which would make it harder to construct browsers. The form based approach would also likely not be very ergonomic for users of line-based Gemini browsers like AV98 and gmnlm.
There is also another aspect to implementing POST, which is that this would make it possible to create more user-friendly content sharing platforms. This isn't necessarily a good thing, however, because such content sharing platforms can quickly turn into content silos. Gemini's current technical characteristics encourage content ownership and technical self-sufficiency, aspects that I would consider to be positive. The slightly higher barrier to entry might also help elevate the quality of the content, although I say that without being entirely sure if it's a good argument to begin with.
But it's also worth keeping in mind that Gemini exists in a world of many protocols, which is a topic ew0k also touches on. At the moment it is entirely possible to create content silos for people to more accessibly produce content, for example by creating a WWW site that utilizes fancy Javascript-based text editors and CMS tools, and since Gemini is by no means going to be overthrowing HTTP anytime soon, I think this is an entirely fair way for less tech savvy people to share their content over to Gemini. I think that's kind of how Flounder works, but I'm not entirely sure since I haven't used it myself.
I wouldn't want Gemini browsers themselves to have to support a multitude of protocols. It would create a lot of complexity and create a potential protocol arms race, which isn't desirable. But I believe it should be reasonable to use multiple protocols in tandem with Gemini such that you can work around the limitations of Gemini's GET.
Suppose for example that we want to create a "gemlogging" platform on Gemini. Since GET is not enough to send long posts, the service provides an email address to send your gemtext formatted posts to. Within Gemini you can tell the server from which email address to expect your posts to come from, and so the server will be able to figure out where each post should go to and discard any spam. Similarly you could leverage FTP, SSH, telnet or whatever other protocols you think you can get away with while still providing some kind of a benefit to being on Gemini. The main worry becomes if you can provide a good enough user experience if the user has to jump through multiple hoops to execute more complex tasks.
Finally, I suppose there's the question of whether or not we should even be trying to implement complex systems on Gemini that would necessitate creation of a POST request in the first place. Many of us are fleeing from the colossally complex technical stacks of the Web, but how seriously do we believe that Gemini would one day replace it and thus necessitate ability to create complex Web-esque software systems? Would we rather prefer that what is being implemented as web applications today be implemented in some other form in a future Gemini utopia? Or is Gemini always going to be just a simple hypertext platform, which will always mainly serve the people managing their own servers and the relatively simple needs they have of CGI scripting? I don't possess answers to those questions and I'm quite undecided on them, but I think they are also worth considering when we're thinking of adding more complexity to Gemini.