💾 Archived View for bbs.geminispace.org › s › misfin › 20790 captured on 2024-12-17 at 15:02:15. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Since I have covered verification within misfin, I also want to cover how I have implemented Threaded view, and some other considerations that need to be made for Threading. Note that this is a client-side consideration, and has been partially implemented in misfin-server's client gemini interface, rather than the server itself.
Threaded view tries to organize messages into threads based on a common topic. It is useful not just for responses to private messages but for public forums, mailinglists, and newsletters that are implemented with misfin.
Since misfin currently lacks global Message IDs, we need a way of keeping track of Threads. The most obvious way to do this is with subject lines (the first gemtext level-1 heading within the body of a gemmail). A message of a particular subject creates a new Thread. Responses to that thread will either use the same subject, or the subject prepended with "Re: ". This is a fairly consistent standard that is easy to implement and keep track of.
Messages are ordered in the Thread based on the timestamp that they are received by the server. This could result in different orders in group messages (and mailinglists) based on the time a particular misfin server has received messages that are sent at roughly the same time; however, this should not have a significant effect as the authors of the gemmails sent at roughly the same time would not have likely seen each other's gemmails anyways. A client could optionally choose to take into account the timestamps other than the last timestamp if, for example, they know or trust that the second-to-last timestamp is from a mailinglist or some trustworthy source.
If two different groups have two separate conversations of the same topic without seeing each other's conversations, this should imply two separate Threads, with exception to mailinglists and newsletters that assume everyone has received or is able to access the threads. In a mailinglist situation, the same subject should always be assumed to be the same Thread, regardless of recipients involved in the conversation, for this reason. For end clients of mailboxes subscribed to mailinglists, this is not something that needs to be specially implemented as mailinglists do not include recipients lines when they forward each gemmail onto mailinglist subscribers.
For private messaging groups, however, Threads should take into account the recipients of the Thread as well as each gemmail's subject. The very first message of a Thread determins its initial recipients, and any messages that include all of these recipients in the original sender line or the recipients line, excluding the mailbox that has just received the gemmail and is assumed to be a recipient, should be attached to the same Thread if they have the same Subject.
If a message from a recipient within a thread adds a new recipient to the conversation (based on the gemmail's recipients line), there are two approaches a client can take: 1. Create a new thread of the same subject but with an expanded recipients list, or 2. Attach the message to the same thread, but add the new recipient to the recipients list of the pre-existing thread. The first method is easier to implement than the second, and has the benefit of clearly notifying users when new recipients are added to the conversation.
If a message from a recipient within a thread removes one of the recipients to the conversation (based on the gemmail's recipients line), the two approaches a client can take are: 1. Create a new thread of the same subject with a reduced recipients list, or 2. Attach the message to the same thread, and *do not* remove the recipient from the Thread's recipients list. In method two, the removed recipient would not have that one message, but they would still be able to reply to any other message from within the Thread. However, it might make more sense to go with the first method because it ensures that a "reply all" will use the reduced recipients list over the original one, and the first method is easier to implement.
Oct 12 · 2 months ago
To me this sounds like overkill. There aren't message ids and what you're doing feels like shoehorning them in. Is there really such a communal desire for multibranched threaded conversations? This seems to over complicate a messaging spec for a web that is both small in features and small in complexity.
As of the moment one can communicate with smolweb using one liner shell scripts and some basic unix tooling. misfin included. I don't know why we would want to add more rules on top of the "be secure and be simple" methodology we seem to have going right now.
@jecxjo this is not part of the spec, but rather advice for implementers who want to do threading with misfin. These aren't rules, simply useful bits of information.
🚀 clseibold [OP] · Oct 14 at 18:21:
@jecxjo I just have to say, when the Gemini community suggests every single thing is complicated and overkill, people start to wonder about the community's competence and minimalist extremism, which seems to be for no other purpose than for minimalism's own sake and viewing oneself as superior.
If you're seriously going to stand here and tell me that threads, a feature we've had for decades in multiple different protocols, including NNTP, SMTP/email, Forums, and BBSs, is not desireable, and that it's overcomplicated because of a few string matchings, then I just have no words for you.
Everything I described above can be implemented in a couple hours with a hashmap. As for the bash scripts, I have no sympathy for them. That's not real programming and people are misusing something that was originally intended for batching commands for running things in the background on multiuser mainframe systems. If things are overcomplicated in bash and batch scripts, it's because you're not supposed to be using them for this stuff in the first place.
As for real message IDs, they also require rules, and actually can be more complicated than the simple method I described above.
While it's not specifically part of the spec, it's a feature of the protocol and will inevitably be something any good client would need to implement because people use and expect it. That's why i question the return on investment for a feature like this.
Right now the message body is gemtext with an optional first line as a header denoting a subject. And the message protocol is relatively out of control of the users or applications. So setting up a subject match along with To/From addressing seems to jumping back and forth and atill only a guess that things are actually threaded.
🕹️ skyjake [mod...] · Oct 15 at 04:14:
@clseibold:
I just have to say, when the Gemini community suggests every single thing is complicated and overkill, people start to wonder about the community's competence and minimalist extremism, which seems to be for no other purpose than for minimalism's own sake and viewing oneself as superior.
Maintaining minimalism while creating something useful and elegant requires a great deal of competence. You do not achieve minimalism by adding features and rules, you achieve it by removing what is not essential.
Rather than doubting other people's competence, we should celebrate the fact that when technology is simple and approachable, it can be used regardless of one's level of skill and experience.
I would say the Misfin(B) that @jecxjo references is more akin to a direct messaging protocol, while the people behind Misfin(C) are trying to build a more well-defined and full-fledged email-like system. There is a difference in mindsets.
@skyjake @jecxjo I have to say I see things a little bit differently. I don't want to contribute to any tension here, it would be really silly to get heated over whether threading is complex or simple or minimalist enough or whatever, but I just want to be clear about a couple of things.
Misfin(B) was intended to be email-like in that it would support multiple recipients and therefore group conversations. It was also compared to email more than any other type of pre-existing protocol and was pitched as 'email for the small web'.
Misfin(C) keeps with Misfin(B)'s spirit by being equally easy to implement and even less extensible.
Everything we are building on top of Misfin(C), from threading and mailbox verification to inbox search and mailinglists, is outside of the core Misfin(C) protocol and while these things serve useful functions, they don't increase complexity for those who want to keep things as technically simple as possible.
What we have is freedom to choose. Everyone can talk to one another using misfin, and just because I use threading and my server verifies that your mailbox exists before accepting messages doesn't mean that you need to implement those things. You are welcome to use a little bash script to send all your messages if you like, and read your incoming messages from the server logs just like we did a couple of years ago. There's absolutely nothing wrong with that.
I say all this because it's actually really important to me to maintain the lightweight approachability of misfin that makes it so much more fun to hack at and play with than something heavier like email. I don't think that's at risk.
Cheers!
@clseibold @satch my comment was never about the complexity and the ability of the community. it was about reflecting on minimalism because one should look at the community's needs and actions.
Look at the gemini client situation. we have dozens of clients with 90% covering the bare minimum. No titan support which honestly is needed to do heavy lifting, most only take one line inputs and don't support new lines so using BBS is a pain. SmolWeb is going to be pet projects that slowly become abandoned so maintaining minimalism in protocol and use helps keep the community alive when the code isnt.
When a misfin client doesn't support threading what will that look like? A huge mess of messages.