💾 Archived View for gemi.dev › gemini-mailing-list › 000914.gmi captured on 2023-11-04 at 13:11:54. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hi, everyone. I was reading carcosa.net's "Re: Comments and pingbacks" article [1], and I ended up thinking about what sort of conversation pattern makes sense in Gemini-space. Gemini is decentralized (which is different from "federated", and I'm happy about that), and this implies to me that a conversation pattern that fits into Gemini-space should necessarily be decentralized. Gemini is human-focused, which implies to me that building a complicated network of automated pingback/webmention/trackback-like things might also be a poor fit. "Overkill" is the word that comes to mind. I wanted something decentralized, lightweight, and participatory. It should require only a small amount of interaction from each person that wants to use it. And it should be something that can be self-hosted, but doesn't have to be. After a bit of searching, I came across the GAMS specification [2]. I liked the spec, but wondered if it might be possible to make an even simpler conversation system. So as an experiment, I made one. It is called "GemThread", and the current implementation is an SCGI service designed to run under Molly Brown. Anyone _can_ run an instance of it, but nobody _must_ run one. The interaction pattern should feel relatively straightforward. To create a new thread:
Raph M. writes:
> I was reading carcosa.net's "Re: Comments and pingbacks" article [1],
> and I ended up thinking about what sort of conversation pattern makes
> sense in Gemini-space.
Thanks for reading!
> Gemini is human-focused, which implies to me that building a complicated
> network of automated pingback/webmention/trackback-like things might
> also be a poor fit. "Overkill" is the word that comes to mind.
I haven't actually published my notes on this, much less written an
implementation (the last couple of months in my life have been *crazy*
and all of my side projects have suffered), but one of the nice things
about the design as it's coming together in my notes is that sending a
geminimention can be done from any Gemini client by following a link and
pasting a URL. That's not clear from what I've published so far, of
course. One *could* automate it as part of a publishing workflow, but
you don't have to in order to participate.
I wanted to write a proof-of-concept before publishing a draft spec.
> It is called "GemThread", and the current implementation is an SCGI
> service designed to run under Molly Brown. Anyone _can_ run an instance
> of it, but nobody _must_ run one.
>
> The interaction pattern should feel relatively straightforward.
---?----snip---?---
Thanks for writing this. It looks pretty good; definitely easy to
understand, and doesn't require self-hosting to participate. I think the
goals of this and Geminimentions are pretty separate. My main goal with
Geminimentions is to help authors be notified of replies (which requires
the participation of the people replying, to be sure). This seems more a
means of gathering replies into a thread, which is probably more
generally useful, but also requires that all participants in the
conversation be monitoring the same instance for replies...
Perhaps I'll publish my unfinished notes as a response on this thread...
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
> > Gemini is human-focused, which implies to me that building a complicated > > network of automated pingback/webmention/trackback-like things might > > also be a poor fit. "Overkill" is the word that comes to mind. > > I haven't actually published my notes on this, much less written an > implementation (the last couple of months in my life have been *crazy* > and all of my side projects have suffered), but one of the nice things > about the design as it's coming together in my notes is that sending a > geminimention can be done from any Gemini client by following a link and > pasting a URL. That's not clear from what I've published so far, of > course. One *could* automate it as part of a publishing workflow, but > you don't have to in order to participate. A couple things come to mind. The first is that my statement above seems as if it could be a criticism of geminimentions, which I _absolutely_ did not intend! I am somewhat disenchanted with the way that some of the indieweb technologies have grown from "small and focused" to "everything including the kitchen sink", and I let that emotion creep into the message. I actually quite like the idea behind geminimention and I am very interested to see an implementation! > Thanks for writing this. It looks pretty good; definitely easy to > understand, and doesn't require self-hosting to participate. I think the > goals of this and Geminimentions are pretty separate. My main goal with > Geminimentions is to help authors be notified of replies (which requires > the participation of the people replying, to be sure). This seems more a > means of gathering replies into a thread, which is probably more > generally useful, but also requires that all participants in the > conversation be monitoring the same instance for replies... My immediate thought here is that it would be easy and probably very useful to create an automated hook in the GemThread service that would call a geminimention URL whenever a response is added to a thread on a GemThread thread. There is nothing in the GemThread implementation that automatically notifies an author of responses, and I feel like that's a pretty significant gap. > Perhaps I'll publish my unfinished notes as a response on this thread... That would be great! There seems to be an obvious intersection between these ideas. I'd be very interested to see your notes! Thank you for the response, and I apologize again if my message came off as a criticism of geminimention. :) Raph
---
Previous Thread: [tech] Gemini reverse proxy
Next Thread: [Tech] QUIC transport protocol is now a standard