-- Leo's gemini proxy
-- Connecting to makeworld.space:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
Recently there's been a conversation around how replies should work in Geminispace, and I thought I'd chime in, as my first *real* gemlog post.
The conversation so far (as CAPCOM tells it, anyway):
Wow, I think that's the longest gemlog chain on Gemini yet! Now time to add mine to mix.
As Shufei has noted, this is all very meta 😄. Replying to each other with gemlog posts, all about the best way to do replies... But somehow it still works, which is a testament to how well this can work even without any formal system at all. But the main motivation for forming a system seems to be the fear that as the Geminispace grows, it'll be easy to lose track of all the gemlogs out there, and so if someone replies to your post, you might miss it. The horror!
To be serious, it could be an issue eventually, but I'm a bit wary of adding more complex systems. I don't want it to become something where setting up a gemlog is easy, but to become a "real gemlog", you should setup, update, and monitor some sort of webmention service. While this might just be the best solution in long run, I don't think there is much urgency here, and we will be okay for a while. As Solderpunk has mentioned, there's nothing wrong with out-of-band lo-fi solutions like just emailing the author to let them know.
I just realized Solderpunk has said the same thing, so I'll put that here too:
> 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.
I completely agree with this, and I think anyone who designs a reply system needs to keep this in mind. It can't require everyone to be a part of it to work.
I'm the author of gemlikes[1], and I've been happy to see all exposure it's getting in these posts, I appreciate it. Not everyone loves it of course, but it was more a fun project than my hill to die on, so I'll take it. Solderpunk mentioned wanting to get that setup on his server, and I'd be very happy to see that at some point.
In the second last paragraph of his post, Solderpunk describes a reply pinging system based on Gemlikes, where Alice (who replied to Bob) could submit the URL of her reply to Bob's site, and then Bob's site would provide that that link to users in some way, through a feed, or more simply, by adding a link to it at the bottom of the original post. This is the solution I like the best out of the ones I've seen, and not just because it uses my tool :)
I would like to implement it. If you want to talk about development of this feature or get updates on it, you can subscribe to
Something I emphasized in the mailing list is that replies need to be accessible by readers. This is the strongest opinion I have on the subject of replies. If all your notifications of replies and replies to replies, etc, happens just by emailing the author(s), then it becomes very hard for readers to keep up with things and know where the replies are. I reject any system that doesn't show the "pings" or whatnot to regular browsers. And so out of the display options that Solderpunk wrote, I am most in favour of just automatically adding the reply URLs to the bottom of the original post. It keeps things simple and very visible to readers. It may be too simple, and suspectible to abuse though, so we'll have to see. But any of the ideas proposed so far (email, atom feed) are easily abused as well, so I think this is a general problem that may need to be solved anyway.
Thoughts? I'd love hear your... reply.
I suppose this is meta as well, but
I encourage you to add the URL of your reply to this post as a comment there, to push meta levels even higher.
Replies:
-- Response ended
-- Page fetched on Thu Apr 25 06:20:16 2024