💾 Archived View for carcosa.net › journal › 20200529-some-replies.gmi captured on 2023-11-14 at 08:13:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Since I've started using gopher, and now Gemini, I've been interested in seeing how people reply to each others' phlogs/blogs/gemlogs. The general trend is: just do it! Maybe include a reference in the title that helps the people you're replying to recognize that it's a reply when they see it on an aggregator...
And there lies the rub. You all have to be reading each others' phlogs, generally because you're listed on the same aggregator site. If someone's not, their reply may be lost in the ether. I know I've refrained from replying to phlogs on gopher for this reason.
The web mostly 'solves' this problem with dynamic comments - or by moving the discussion off of the blogosphere entirely and onto social media. Medium handles it in the worst way, by centralizing blogging and collapsing the blog-comment distinction with the worst possible UI.
There have been a few recent attempts to create comment systems on Gemini[1][2], but none of them really preserve what I want to see – the practice of responding on one's own blog.
In the old days, blogs had pingbacks, though I never got those working, and today the Indieweb has Webmentions. I'm pondering a simplified Webmention-like protocol for Gemini, but it's still pretty half-baked. And to "show code", I'd need to either change to a server that supports CGI, or add extension support to Germinal... which I've been pondering doing, but really don't have the time...
[1] Geddit: a Reddit-type aggregator for Gemini
[2] Gemlikes: a liking and commenting experiment
I am feeling better, thank you. My lack of gusto for alt-computering has receded, but I find myself without the time to do anything about it! I've had the tutorial/overview for Radiance[4], a Common Lisp web framework in my Wallabag since 2020/05/06, and haven't so much as fired up SLIME to write a "Hello World" application for it. Similarly, extension support for Germinal...
As for a brutaldon-like journaling software for Gemini: it's certainly possible, but I'm slightly negative on the idea for a few reasons. One is that the user experience is not likely to be great, given the intentional limitations of input in Gemini – there's no equivalent of a textarea, and every field of a "form" is a separate request. Also, there's authentication and authorization to work out, and I'm kind of waiting to see how the workflow for client certificates shakes out.
The final thing is that I'm not sure I'd really want to have it be a Gemini app, at all. Even though brutaldon is very sparse and restrained for a web app, it's still an app; it kind of carefully treads the boundary between full-blown application and dynamic web document. I'm kind of hoping Gemini stays solidly on the document delivery side (though dynamically-generated documents, like search result pages, are good). The web has tended to swallow all activities into the browser, edging aside non-web applications. I'd like to see programs that are adjunct to Gemini come into use.
I might be interested in writing a CLI, TUI, or GTK app for maintaining a gemlog, but it would basically be a wrapper around rsync and gemfeed. Or were you thinking of a web application for maintaining a gemlog? It strikes me as a slightly perverse idea, but it does make it usable on mobile easily...
I'm going to consider the Mercury Protocol as just a thought experiment, not something Solderpunk is threatening to move to. I agree with many people on the Gemini mailing list that it doesn't solve enough gopher problems to encourage people to adopt it the way people have been adopting Gemini.
Also, I think the only open question about Gemini that is really contentious or complex is the handling of client certificates. All of the document formatting discussion (alt text on pre-blocks, etc.) are likely to shake out quite soon on the list and in practice; the same for language metadata.
I may have been the person who originally suggested transient client certificates as a more restrictive substitute for session cookies. If so... I officially apologize. I was thinking that it would be nice to be able to make server-side apps for Gemini comparable to brutaldon. But after publishing a gemlog for a while, I've kind of lost the desire to do that, and think that allowing Gemini to become an application platform is probably not a good idea. We still need client certificates to secure private documents/areas, and arguably to use for identities in the way that Sean Conner originally used on his site. But I'm afraid that clients are going to be too hard to implement if they have to do a lot of certificate management...