gemini://soviet.circumlunar.space/oak/mailinglist/11.gmi

Date: Wed, 06 Jan 2021 20:50:35 +0100

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

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.

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

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

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

> 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

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.

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...

Type: application/pgp-signature

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.

> /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

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.

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

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.

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...

Type: application/pgp-signature

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

> 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

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

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"?

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

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.

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...

Type: application/pgp-signature

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"?

> 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

> 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.

Date: Thu, 07 Jan 2021 23:19:36 +0100

There is now a board following the draft specification at this address:

Feel free to send me your information to take part in the experiment (details in the only thread of the board).

[tech] Gemini Acentred Messaging System

From: come at chilliet.eu

From: Leo

From: Alex // nytpu

From: come at chilliet.eu

From: Alex // nytpu

From: Jason McBrayer

From: Johann Galle

From: come at chilliet.eu

From: come at chilliet.eu