Gemini and POST, Part 2

I've had a whole lot of feedback on my previous post, through IRC, email and gemlog responses:

Sakurina's response

Samsai's response

Thank you all! I'll try to collate and summarize your responses and my own further thoughts here.

Titan and Dioscuri

The Titan Protocol

The Dioscuri Protocol

These protocols are subtly different, from what I can tell. Dioscuri runs on its own port and demands authentication, whereas titan is handled by the gemini server (if it supports it) and allows POST with an authorization token only. Both are definitely valid solutions, but as I pointed out in my previous post I don't think a heap of competing standards/protocols is desireable.

That said I think they're both neat. Kudos to John and Alex for working on them :)

EDIT (2020-11-23): John Cowan politely pointed out that Titan is a PUT protocol, while Dioscuri is a POST protocol. I made no difference between the two in my musings, but it's worth noting that there *is* a difference. Consider the following explanation from StackOverflow:

> PUT puts a file or resource at a specific URI, and exactly at that URI. If there's already a file or resource at that URI, PUT replaces that file or resource. If there is no file or resource there, PUT creates one. PUT is idempotent, but paradoxically PUT responses are not cacheable.

> POST sends data to a specific URI and expects the resource at that URI to handle the request. The web server at this point can determine what to do with the data in the context of the specified resource. The POST method is not idempotent, however POST responses are cacheable so long as the server sets the appropriate Cache-Control and Expires headers.

"What's the difference between a POST and a PUT HTTP request?", StackOverflow

SFTP and Friends

Tomasino pointed out in the IRC chat that FTP/SFTP used to be a common tool for all sorts of office workers only a couple of decades ago. There are several very user-friendly clients for it already.

Starting a blog on the web includes choosing a CMS vendor and signing up for a portal, and then tinkering with themes, stylesheets, plugins, etc until you've learned enough to publish posts in a way that isn't horrible for the typical web user to view.

In geminispace the corresponding process is to choose a tilde (at this point; other publishing options may show up in the future) and learn a way to transfer files to the right directory. The learning curve isn't really steeper, just different.

Specialized Portals

Another way to approach things is specialized tooling. One example is Sloum's web portal for gemlog publishing:

Sloum's gemlog.blue

Another, which I believe is still hypothetical, is apps for publishing content.

What's Left to Say?

I dunno. I think the state of gemini is and will be that it's a GET-only protocol. It's by design, and I'm leaning more and more towards the opinion that this is a good thing. My original request for a POST method is based on a web-centric frame of reference. But when you look closer, the POST method on the web is not a solution in itself; it's simply a tool that helps web developers build any specialized portal on top of the web itself. That's not at all what I want.

For the future of publishing in geminispace I believe that SFTP will be the most common option, and if geminispace would somehow become popular enough to rival the web I think specialized tooling for different portals is a good option.

The web-centric in me still wants to see wikipedia-like capsules in geminispace, that any gemini browser can access without knowing any other protocols. But I've come to believe that it's not worth the added complexity, and I find it a creative and interesting challenge to see what kind of solutions we can all come up with within the frame of the existing specification.

-- CC0 ew0k, 2020-11-07