Client Threaded View

by clseibold on October 12th 2024

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.