💾 Archived View for pn.id.lv › 20220227.gmi captured on 2022-07-16 at 14:35:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-05-25)
-=-=-=-=-=-=-
It appears that just recently the topic of Gemlog response notifications has picked up somewhat. I wrote my own proposal about a week ago, and more recently bacardi55 has written one of their own too, which in turn seems to have prompted some discussion around the concept in general.
RE: A More Concrete Proposal of Gemmention
RE: My take on gemlog responses
RE: Have one's cake and eat it - likes, comments, backlinks and so on
RE: re: Have one's cake and eat it - likes, comments, backlinks and so on
There have been good points raised. Additionally, I want to refine my own position on this, given that thus far I haven't talked about my motivation of posting my own proposal in the first place, apart from a brief aside in the proposal.
If Gemmention, etc. were not to exist, communication by default seemingly defers to e-mail. E-mail on its own is a fairly heavyweight approach to communication; by convention, it encourages writing of full-blown letters as opposed to brief notes that are usually more often found with, say, IRC.
For me, this was the primary motivation for outlining Gemmention: specifying something with limited power to express a very particular kind of interaction via a lightweight means and without accidentally engaging in an inline conversation. If a conversation needed to be had, that'd either happen in public over the gemlogs, or in private when a participant explicitly chooses to.
That said, because of the way Gemmention borrows heavily from Webmention, it turned out more complex than I had wanted, and one avenue it fell short of was that it's needlessly hard to use manually (i.e., by typing the URL with the query parameter in a regular browser), and the fact that it requires two parameters to be stuffed into the query string makes it feel really un-Gemini-like. I remain conflicted and unhappy with it.
The approach by bacardi55, which in large part happens to line up with Solderpunk's and JFM's outlining of a mention protocol, is much simpler and happens to be perfectly usable from a browser without any specialized software – in fact, the first response notification sent to bacardi55's server (I presume, therefore the first such response to ever happen outside development, if I may be pompous for a moment) was sent via me typing the URL manually out in Astronaut.
A placeholder on Gemini replies
As I envisioned Gemmention and how I believe bacardi55 views gemlog responses, they are explicitly optional. I'd even go as far as to say, in the spirit of the IndieWeb, that at the current scale mentions should explicitly *not* be automated. At least, that's how I'm approaching it: I review my received mentions occasionally, and I don't have software send them out for me.
indieweb: manual until it hurts
Stepping into an observer's shoes, I can understand how having a spec before an implementation might seem as though that's encouraging automation. My reason for writing the specification was not such; I intended to encourange interop before automation, to let others know how to use my (admittedly Rube-Goldberg-ian) scheme. One thing that bacardi55's scheme accomplishes and mine doesn't is that it is much more lightweight in the manual case, and doesn't require additional software to be enacted, apart from a CGI script to collect the mentions.
All of the above taken into account, I have a suspicion that a lot of the discussion thus far has explicitly been centered around gemlogs in particular as the potential subject of such a technology. And, given that this response itself is part of a gemlog, I guess it's inevitable to succumb to the same. But I want to step back for a moment.
Gemini as a protocol itself is generic towards the content it serves. While yes, currently a large part of the appeal of Gemini is access to gemlogs from great people all around the world, I personally hold the view that Gemini can serve as a basis for more than that. Perhaps some view this as heresy; I don't judge those who think so, I'm here primarily for my own sake without any ideological narrative to push.
I've talked before about Gemini's brutal but still useful simplicity, in most times having only one obvious way to do things. This simplicity is a limitation, and limitations encourage creativity; the things that the Gemini community has done in the couple of years of its existence is proof of that – Gemini need not only be used for gemlogs, it can also accomplish more.
In that sense, I wanted Gemmention to be this kind of a building block for other uses for Gemini, even beyond gemlogs. I primarily wrote it down to have it documented, in case anyone else wanted to interact with my pod in this way, but I don't expect it to take off beyond that (and it hasn't.) Perhaps when someone comes up with a use case that might see use to it, then it might come in handy, and I fully acknowledge that defining a standard without actually having a use case demand it is a bad praxis, but what's done is done, and I don't see it meaningful to retract it.
On the other hand, the fact that until now the smolweb has managed just fine without this sort of a unified proposal might instead imply that it doesn't have any reason to be. And that's fine too! The critique listed by others thus far implies that Gemmention probably doesn't have place in the wider gemlog community, and so be it.
I respect the opinions of skyjake, StackSmith, szczezuja, bacardi55 and others, and I genuinely enjoyed reading all the aforelinked responses. That said, I still stand by my opinion that it's possible to grow Gemini and the smolweb in a way that continues to maintain its counter-commercial, counter-expansionist and pragmatic minimalist mentalities while also allowing new applications to arise within them, be that as it may.