💾 Archived View for skyjake.fi › gemlog › 2022-02_re-gemlog-responses.gmi captured on 2022-03-01 at 15:10:42. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
bacardi55 et al. have proposals about automating gemlog response notifications:
I feel like interacting with each other over gemlog entries remains difficult. At least to ensure the author see all the responses to their posts.
To me these proposals feel like Web technology. They are (relatively) complex technical solutions that are difficult to apply universally to everyone, and require (relatively) costly commitment from both gemlog authors and readers.
Gemlogs are not meant for interaction, per se. It's a bit like having a discussion with someone by publishing open letters in a newspaper. It's a many-to-many, open ended forum.
Gemlog discussions have a certain stress-free nature. You can just make a post and not worry about any replies, or deal with them at your leisure after a week or a month. It's a slow, disengaged form of communication, amendable to an intermittently-offline way of life.
Should we try to build a two-way communication channel out of gemlogs? I'm leaning on "no": it adds complexity for everyone, and it's better to converse over existing channels that are actually designed for such interaction.
There is a concern over centralization:
it seems that we are more and more relying on "centralized" services. [...]
Any services, as on the web, could disappear at any time and that may be even more the case in our very small space.
This is a real risk. However, there is a big difference between actual centralized services and centralized _indices_. Twitter is a centralized service, for example: all the content and interaction happens via a single site. Centralized indices, on the other hand, present a view to decentralized information in a single place, like a search engine, gemlog aggregator, or Cosmos. It is detrimental if one of these disappears, but such indices are replaceable and rebuildable.
I do know that asking capsule owners to deploy a script will be the biggest concern here, but I guess there is always a "price to pay".
In my opinion, requiring a CGI script is a deal killer. Gemini servers don't have to implement CGI, and popular ones like Agate only serve static content. A gemlog can and should be as simple as a directory with a bunch of text files, everything written by hand, served by a basic "read-only" server.
A "simple" solution would be going to the capsule, find the contact of the author and send an email… But not every capsule has a contact page and the process is very manual, requiring to use another tool and protocol to communicate.
I think using email is the right solution here.
Since some sort of manual action is anyway required from the replier, I recommend using "mailto:" links. They are more powerful than one might suspect, since it's possible to include fields like subject, CC/BCC, and even body text in the mailto URI. With these, one can include a "Notify me" link on their gemlog post that's just as functional as a CGI entrypoint would be, but only requires a regular email client. The recipient will automatically also get your email address to continue the conversion, if appropriate.
If one's server is advanced enough, such mailto URIs can include fields tailored specifically to the post in question, but a manually composed mailto link is sufficient for the purpose, too. (Here's one:)
📅 2022-02-27
🏷 Gemini
CC-BY-SA 4.0