💾 Archived View for gemi.dev › gemini-mailing-list › 000608.gmi captured on 2024-05-26 at 16:17:19. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello, I would like to propose a specification for a board system allowing to reply to each other through gemlogs. There have been some attempt at forum-like gemini capsules in the past, such as motm (gemini://illegaldrugs.net/cgi-bin/motm/boards), and most of them are based on Gemini input request, or require use of another protocol such as Titan, Inimeg, Dioscuri? There is also GUS backlinks, which may be used to check if someone replied to a gemlog post, but GUS is seldomly updated, and not everyone is checking backlinks to its gemlog posts. So, the idea behind GAMS is to use gemlogs to reply to each other, and have a board capsule which lists threads and responses. This allows to use a really simple setup, and avoid needing an auth system, or an upload protocol supported by gemini clients. Another nice thing is that you can post on several boards using the same gemlog with different tags (allowing for subject-specific, or language-specific boards). The draft specification is here: gemini://gemlog.lanterne.chilliet.eu/GAMS.en.gmi Any feedback is welcome. I originally intended to annouce this with a working capsule directly, but I?m having a hard time finding time to implement a board, and I wanted to do something completely based on text/gemini files for data to avoid using a database and it?s harder than anticipated. I still think I will post a POC in a few days/weeks, but it may be instable. C?me
Haven't read the spec yet, but I think something similar to webmention [1] [2] from the IndieWeb guys might work well. [1]: https://indieweb.org/Webmention [2]: https://en.wikipedia.org/wiki/Webmention -- Leo
I really like this idea! Mixing the ease of writing, simplicity, and asynchronicity of gemlog replies with the ease of reading on a centralized page instead of searching out all the relevant posts on an aggregator. I link to GUS' backlinks on my own gemlog, but by the time GUS updates (last updated: 2020-12-06) my posts are usually over a month old, making the backlinks practically useless to anyone following the conversation as it unfolds. Another way to have these sorts of conversation are in order, saving people from having to make posts listing the full conversation like: gemini://republic.circumlunar.space/users/flexibeast/gemlog/2021-01-06.gmi Some feedback: > I originally intended to annouce this with a working capsule directly, > but I?m having a hard time finding time to implement a board, and I > wanted to do something completely based on text/gemini files for data > to avoid using a database and it?s harder than anticipated. I see no reason why your board server couldn't use a database (or a non-gemtext file format) in the backend. It would probably make it a lot easier when querying and parsing since you can use a custom structure that suits your internal data format, then just render to gemtext once you're done. > The board should present a threaded view of messages I have mixed feelings on threaded forums in general, but if you think it's best it it's not the end of the world. However, it would /significantly/ simplify implementations if you just chronologically grouped messages by post tag. You'd no longer have to query every single tagged post and find the first link, instead just querying the gemini feed page, saving lots of server time and bandwidth for both the board hoster's server and the post author's server. However, this non-threaded approach creates a problem. This is the only situation I've come across so far that is actually limited by the gemini feed's no timestamp limitation. Since conversations can happen in the span of a day, it would make it hard to group them. This would be the main reason I could think of for keeping the threaded design currently proposed. I dunno, it's something to ponder on. I do love the idea though, and will be trying out your implementation when it's done. ~nytpu -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210106/3216 f154/attachment.sig>
Le mercredi 6 janvier 2021, 21:47:27 CET Alex // nytpu a ?crit : > I see no reason why your board server couldn't use a database (or a > non-gemtext file format) in the backend. It would probably make it a > lot easier when querying and parsing since you can use a custom > structure that suits your internal data format, then just render to > gemtext once you're done. There is no reason other than it was what I was feeling like doing. I dislike setting up and using databases and I liked the idea of having something really simple, and as static as possible. But of course another implementation of the same specification could be built upon a database and even be fully dynamic. > > The board should present a threaded view of messages > I have mixed feelings on threaded forums in general, but if you think > it's best it it's not the end of the world. This is a presentation advice, but a board server may chose to list messages in an other way. > However, it would > /significantly/ simplify implementations if you just chronologically > grouped messages by post tag. You'd no longer have to query every > single tagged post and find the first link, instead just querying the > gemini feed page, saving lots of server time and bandwidth for both the > board hoster's server and the post author's server. > > However, this non-threaded approach creates a problem. This is the only > situation I've come across so far that is actually limited by the gemini > feed's no timestamp limitation. Since conversations can happen in the > span of a day, it would make it hard to group them. This would be the > main reason I could think of for keeping the threaded design currently > proposed. I like the idea of replying to a specific message of the thread, as we do on mailing list. Maybe I should add the requirement that the post link to the board thread as well as the post it?s responding to. This would ease updating because you know exactly in which thread a message goes without searching in the thread. But I liked the simplicity of just linking to what you are anwsering. C?me
On 2021-01-06 10:36PM, C?me Chilliet wrote: > There is no reason other than it was what I was feeling like doing. I > dislike setting up and using databases and I liked the idea of having > something really simple, and as static as possible. Oh, it's a personal choice for your implementation, that's obviously perfectly fine. I was thinking it was a requirement for all implementations or something like that. > I like the idea of replying to a specific message of the thread, as we > do on mailing list. I guess the fact that it's using gemlogs (which are usually longer-form than your average comment on a forum) as the posting medium mitigates my main complaints with threaded forums?namely, encouraging low-effort or otherwise filler comments and encouraging tangential and off-topic discussions. Upon thinking about it more, I think threaded would be fine or preferable for this style of board. > Maybe I should add the requirement that the post link to the board > thread as well as the post it?s responding to. This would ease > updating because you know exactly in which thread a message goes > without searching in the thread. But I liked the simplicity of just > linking to what you are anwsering. I think it would be best to just link to what you're replying too as well. As long as you take uri normalization and encoding into account, it wouldn't be any harder to match a link to an arbitrary post in a thread as it would to match the base board link. -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210106/e73a 6b5e/attachment.sig>
C?me Chilliet <come at chilliet.eu> writes:
> I like the idea of replying to a specific message of the thread, as we do on
> mailing list.
>
> Maybe I should add the requirement that the post link to the board thread as
> well as the post it?s responding to. This would ease updating because you know
> exactly in which thread a message goes without searching in the thread.
> But I liked the simplicity of just linking to what you are anwsering.
If you're getting into threading, and reconstructing a thread from
back-references that may be incomplete, you should definitely read this:
https://www.jwz.org/doc/threading.html
It describes how threading was implemented for both mail and USENET in
Netscape Navigator. Besides providing an algorithm, JWZ also shows that
you don't need a database to do it (even for efficiency).
If you include one link in the head of your post format, that's
equivalent to "In-Reply-To"; if you include all the links back to the
root, that's "References". There's no equivalent to including the root
and the parent, but maybe you can see how that would affect the
algorithm.
BTW, I want to say I really like the *idea* of this way of doing a
board, for several reasons, not the least of which is that it does not
involve bolting on any kind of POST semantics to Gemini.
--
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
Hi there, On 2021-01-06T20:50+01, C?me Chilliet wrote: > Any feedback is welcome. Alright I'll have a go because the specification is nice and short, which is good. My points are ordered from least to most important IMHO. from <gemini://gemlog.lanterne.chilliet.eu/GAMS.en.gmi> (revision 1): > When someone wants to register..., it sends... I think that should be "they send"? > ... gemlog ... I assume you are referring to a capsule in the format of the companion specification "subscribing to gemini pages" with this. Maybe I am being overly pedantic, but it might be nice to point it out explicitly. > * convention for thread page naming? You have taken a quite liberal approach with the rest of the specification, so I don't think you'd need to add this to it. > The date must not be in the past or future. Seeing that the crawler will probably not pick up the post in real time, this is a bit strict. Maybe relax it to something like "not before the last post", because I think that's what would most likely be used in practice: Filter out any posts that are older than when the board last checked that gemlog. > ..., containing the tag enclosed in square brackets in the title. I personally would think of the tag as including the brackets, but that is bikeshedding. More importantly: It might be simpler if the tag was just a URL/domain of the board or something like that. On the other hand that would eliminate something like posting to mulitple boards with the same tag. But that practice would IMHO only create problems e.g. when replying to someone on one board and it also shows up on another, but the OP is not there. And using the URL/domain would be a nice way to make sure the tags are unique. > When creating a new thread, link to the board homepage instead. > [...] > * Handling of errors, like first link to unknown page I think it would be the easier solution to create a new thread if the first link is to an unknown page, or if there is no link at all. If you think about how threading works with e-mail, it also works that way. And yes sometimes it breaks if the headers are not set right, but it will not be possible to build a perfect system with this eiter. Regards, Johann --- You can verify the digital signature on this email with the public key available through web key discovery. Try e.g. `gpg --locate-keys`... -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210107/ac65 a9ca/attachment.sig>
Le jeudi 7 janvier 2021, 17:25:36 CET Johann Galle a ?crit : > from <gemini://gemlog.lanterne.chilliet.eu/GAMS.en.gmi> (revision 1): > > When someone wants to register..., it sends... > > I think that should be "they send"? Yep, fixed. > > ... gemlog ... > > I assume you are referring to a capsule in the format of the companion > specification "subscribing to gemini pages" with this. Maybe I am being overly > pedantic, but it might be nice to point it out explicitly. I am referring to this specification when using the word ?gemfeed? in the section ?The board?. I could link to it, but thinking about it we may also live out of the specification which feed format are supported, if a board author wants to support atom or rss it would work too, they just have to indicate it to potential members. > > * convention for thread page naming? > > You have taken a quite liberal approach with the rest of the specification, so > I don't think you'd need to add this to it. Well the idea was to be able to link to the board thread before it is created, from the post creating the thread. For this it helps if the thread URI is predictable. But yeah, it may be specific to a board. In my tests so far I use a truncated sha1 of the URI of the first message. > > The date must not be in the past or future. > > Seeing that the crawler will probably not pick up the post in real time, this is > a bit strict. Maybe relax it to something like "not before the last post", > because I think that's what would most likely be used in practice: Filter out > any posts that are older than when the board last checked that gemlog. This is bad wording. What I meant was that if you post a post on january 6th but date the post january 5th, the specification does not garantee that the board will see it. Of course when the board crawls a feed, it fetch all messages dated from last visit (but last visit may be in the same day, in which case all messages dated today are fetched). Feel free to suggest modifications to the text to make this clearer. > > ..., containing the tag enclosed in square brackets in the title. > > I personally would think of the tag as including the brackets, but that is > bikeshedding. > > More importantly: It might be simpler if the tag was just a URL/domain of the > board or something like that. On the other hand that would eliminate something > like posting to mulitple boards with the same tag. But that practice would IMHO > only create problems e.g. when replying to someone on one board and it also > shows up on another, but the OP is not there. And using the URL/domain would be > a nice way to make sure the tags are unique. The tag needs to be in the message link from gemlog index, other links are not fetched, so board URL is too long to be used here. > > When creating a new thread, link to the board homepage instead. > > [...] > > * Handling of errors, like first link to unknown page > > I think it would be the easier solution to create a new thread if the first > link is to an unknown page, or if there is no link at all. If you think about > how threading works with e-mail, it also works that way. And yes sometimes it > breaks if the headers are not set right, but it will not be possible to build a > perfect system with this eiter. Hum yeah that may be the best in practice. But I liked the idea of pointing to the board when posting a thread, so that people which do not know about the board can find it. But it may be just good practice and not specification per se. Thank you for your input. C?me
There is now a board following the draft specification at this address: => gemini://gams-en.lanterne.chilliet.eu/ Feel free to send me your information to take part in the experiment (details in the only thread of the board). C?me
---
Previous Thread: [ANN] Schapcom
Next Thread: [tech] A '.well-known/' path for contact information?