Support for MSC3440 (Threading)

[anlumo]

Feature Description

Element implements MSC3440. It adds another hierarchical level to channels, where responses aren't inline in the main chat, but separate "sub-channels". People can create new threads and post messages to threads.

Rationale

This feature is excessively used in many of the larger channels I'm in. Fluffychat looks really enticing, but without that feature, all of the responses are within the same stream and so I don't know what the messages are a response to, and I also can't participate. This makes it impossible for me to use the client in practice.

Mockup

I can't really draw them out, but I can write out some text:

The way Element implements Threads is not so great, because they're hard to reach and easy to miss. I personally prefer the way Discord does them (which is identical from a features perspective). Luckily, they have a nice introduction here with animated gifs.

If there are any unread messages in a thread on a channel you haven't muted, these threads are added in the channel list as a lower level row (making it a tree view). Clicking on them directly opens up the thread (which looks identical to the regular channel view). The back arrow button on the top left moves back to the main channel.

If you want to look at a thread without unread messages, there's an action button on the top right within the channel to open up a side panel (or popup) listing all threads showing the last message plus a timestamp. Clicking on a row there opens the corresponding thread view (as above).

Additional Context

No response

[wapsi]

Are there any plans to implement threads in FluffyChat (is it in the roadmap)? I really want to use FluffyChat as my primary Matrix client, but the missing support for threads is a show stopper for me :( (been using them extensively in Element and it's a killer feature!)

[Akselmo]

I wouldnt mind to be able to hide them since theyre quite confusing in middle of regular discussions. Proper support would be nice of course.

[PinguDEV-original]

Any plans here?

[notramo]

@krille-chan, this is the most upvoted issue

I would be happy to donate via Polar, specifically for work on this issue, and I'm sure others would too.

[krille-chan]

I will see what I can do :)

[LordMZTE]

Any updates on this?

[krille-chan]

Any updates on this?

Not yet, sorry. 😔 Will probably take more time

[tuxayo]

Maybe an intermediate step would be to show threaded messages as each being a response to the previous one. That would make discussions much more followable.

And the next intermediate step would be that responses are sent to the server as responses in the thread. Not responses in the main discussion. That would allow to not mess the flow for other clients when responding.

Both hopefully would have most work reusable for a full implementation so that might not be much of a detour.

[udjer]

There is actually a current issue with threads, that manifests itself when using FluffyChat and Element Desktop for the same account.

To reproduce (in a room, where a thread exists):

• use FluffyChat to reply to a message in the thread (can be checked in Element);
• open the room in question in Element while threads are closed (possibly restart Element) to find this reply in the main channel;
• open the thread (still in Element) to watch this reply vanish (in the main channel, and not to be found in the thread either).

Colleagues have reported that this issue does not occur with mobile Element Apps, in the Element Web App it seems to be present as well though.

Of course, this may be a problem of how threads are implemented in the Element client - but it would certainly vanish if FluffyChat supported threads ;-)

Perhaps [Disclaimer: I am neither a professional programmer nor do I know the MSC3440 specs] a first step could be to keep track of the thread by adding the thread root id to messages (replies) in a thread, so that threads remain intact in the Element client? As far as I can see the code seems to read something like

"m.relates_to": {
      "event_id": "<root msg-id>",
      "is_falling_back": true,
      "rel_type": "m.thread"
    }

In replies created by FluffyChat, the "m.relates_to": { ... } seems to be present, but the information relating to the thread is not there (perhaps this info can be simply copied from the message replied to?).

From there, it is of course still a lot of work to actually implement the display of threads (I suppose) - but the message infrastructure would be present.