[tech] Gemini Acentred Messaging System

[Alex // nytpu]

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://mailing-list-archive.gemi.dev/www/attachments/20210106/3216f154/attachment.sig>