💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › gemlog › replies-in-geminispace.gmi captured on 2023-04-19 at 22:59:48. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Replies in Geminispace

Geminauts JFM and Shufei have been conversing of late (and there's been some discussion on the mailing list, too) about how the notion of "replying" to things should look in Geminispace:

gemini://carcosa.net/journal/20200529-some-replies.gmi

gemini://gemini.circumlunar.space/~shufei/phlog/20200529-Reply-ProstheticConscience.gmi

I think this is an important conversation to have, and I wish I had the time and energy to participate in it more actively myself.

I am generally a fan of Gopher's convention of replying to posts with a dedicated follow up post. I haven't ever really missed "web style" commenting in that environment. However, as JFM rightly points out, this approach has real discoverability problems, and does not scale. It works nicely in Gopherspace (or at least the part of Gopherspace I inhabit) because it's a small and close-knit community where most people read most other people, and people can fairly reliably keep track in their head of who they know to be following them. Geminispace is arguably already in danger of losing this property, due to the recent rapid expansion. I have certainly been stumbling upon responses to my "Mercury protocol" post many days after they were written! So, there is a clear need for something more.

Of course, this *could* be something as simple as people emailing authors to say "Hey, I've replied to your post on X over at Y". It's lo-fi, but it'd work. The original author could edit their post to link to responses which they think are worth sharing with their readers. Substitute XMPP or the Fediverse if email is too old school for you. For many people, there may be no compelling reason to consider anything more than this.

That said, trying to adapt ideas from the web, like pingbacks and webmentions, seems a sensible thing to explore and I will keep a curious eye on any developments in that direction. However, I'm kind of concerned about how quickly this might lead to it being commonly expected that putting content into Geminispace means running some kind of serverside "framework" to handle this stuff for you. That's a big step up in what's required to participate, and barriers to entry like that discourage self-hosting, which is sad. There is so much to be said in favour of simple, static sites which can be managed by dumb and generic tools. This is all I've ever used in Gopherspace, or Geminispace so far, and I'd be reluctant to move away from it.

It's also been mentioned on the mailing list that traditional comment-threads have real value, in making it easy for people to read all the parts of a back-and-forth exchange in one place with clear context. This is especially true for technical content, where people might be asking questions about a post and the original author may provide clarification that's beneficial for everybody to read. All very good points. Thankfully, there's now a CGI application to provide just this kind of functionality for Gemini sites:

Check out "Gemlikes", by makeworld!

I haven't yet stumbled across any deployments of this beyond makeworld's own demo, but perhaps this will change over time. Sadly I can't set this up at gemini.circumlunar.space yet because Molly Brown's CGI support has security problems. I hope to implement SCGI in the near future to work around this, but I can't promise it will happen any time soon.

Something like Gemlikes could, of course, function for response notification as well. Instead of leaving an actual comment for the author, you just submit the URL to your response post at your own site. The backend software then fetches the provided URL (anything submitted which *isn't* a URL is summarily discarded), and if it's text/gemini content which contains a link back to the original post, then it is recognised as being a response (anything submitted which isn't text/gemini or which doesn't link back to some original content on the server running the backend is discarded) and the backend does something appropriate - informs the author via email, inserts a link at the bottom of the original content if it's being dynamically formatted, adds the response to an Atom feed, etc. Whatever people want to setup. Actually, I quite like this approach. Because the backend checks whatever URL it is given for a relevant link back, it is capable of figuring out all by itself which particular post is (or posts are!) being responded to, so unlike with comments there is no need for different per-post submission URLs. A single URL is sufficient for the entire site, so a link to it could easily be added to the bottom of every post by a very simple static templating system, or even by hand. We could standardise on what form that URL should take (making it a well-known endpoint, like robots.txt) to make up for the fact that text/gemini has no way to declare the URL like a HTML page would with a <rel> link (open question: how do we get this well-known URL idea working nicely with multi-user sites like pubnixes?). This would then enable automating the whole process in a sufficiently powerful bit of software, like the Live Journal client for Windows that Shufei mentioned.

Some people might find this idea wonderful, while some might consider it far too much bother to setup for their Gemini capsule. That's okay, there's no need for a one-size-fits-all solution. If Gemini really does take off and become considerably larger than Gopher, then I think it's more or less inevitable that it will develop different "subspaces" with different norms and conventions. Some people can run simple, fully static sites with no interactivity at all, other people can have their entire site generated dynamically by some kind of framework which provides commenting and other such features. Or anything in between. People can limit their participation to the like-minded or explore more widely as they see fit. Since the entire protocol has been carefully designed so it is not easy to do anything really awful, there is no reason to discourage experimentation and diversity.