💾 Archived View for soviet.circumlunar.space › oak › mailinglist › 11.gmi captured on 2024-06-16 at 12:59:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
Date: Wed, 06 Jan 2021 20:50:35 +0100
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
--------
Date: Wed, 06 Jan 2021 23:18:51 +0300
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
--------
Date: Wed, 6 Jan 2021 13:47:27 -0700
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/3216f154/attachment.sig>
--------
Date: Wed, 06 Jan 2021 22:36:04 +0100
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
--------
Date: Wed, 6 Jan 2021 16:25:44 -0700
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/e73a6b5e/attachment.sig>
--------
Date: Wed, 06 Jan 2021 21:58:06 -0500
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
--------
Date: Thu, 7 Jan 2021 17:25:36 +0100
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/ac65a9ca/attachment.sig>
--------
Date: Thu, 07 Jan 2021 21:08:12 +0100
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
--------
Date: Thu, 07 Jan 2021 23:19:36 +0100
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
--------