Element-web: Threaded Messaging

[ajvsol]

Extending the Quote functionality to allow for threaded messaging.

This could be a simple 'Quote 2.0'-style like WhatsApp where the quoted text is hyperlinked and when clicked makes you scroll up to their message:

Or the more sophisticated Threaded Messages panel like Mattermost:

Perhaps allowing for both could be done by having the Threaded Messages panel open when you left-click on the 'reply' part of the Quote 2.0 message:

Or by having 'Message Thread' popup as an option in the context menu to allow opening the Threaded Messages panel:

[ara4n]

The plan is to do _REALLY_ good threading in Riot. There's a lot of work on this currently on the Matrix spec, backend, and we're starting work on the frontend next week. #1792 is the design bug for this (although there's nothing there yet). I'll keep this one around too. Thanks for the overview of what other folks are up to here!

[ajvsol]

Looks like Slack have implemented this now as well.

Cool UI:

And an overview page:

[clopez]

flowdock also implements threaded conversations in a nice and very usable way

https://www.flowdock.com/help/chat

[ghost]

Twist from creators of Todoist uses the very interesting concept of threaded channels:

In these channels every message must be in a thread, and it makes conversations much more organised than a continuous stream of messages.

It's the modern version of forum, except you get the benefits of organisation and don't miss out on integrations, mentions, presence, bots etc.

[richvdh]

this is not p1.

[markwooff]

I believe this should be a p1 issue, almost all other chat platforms have some sort of implementation of threaded messages. Would be happy to assist in the development of this!

[colans]

I see this as more of a nice-to-have. Slack didn't even have it for a while. I'd say #4406 is more important as there's currently no way to reset the message pointer, which most other systems have had for a while.

[britthurley]

I definitely see this as a p1, not a nice to have. Constant noise is a major complaint for utilizing chat platforms in business settings, and threading cuts down on that noise by grouping conversations and allowing a user to essentially ignore it. This was a major improvement in Slack, and most people who have used threaded messaging do not want to go backwards.

[tysonclugg]

I'm evaluating Riot.im for use at my work and with a couple of NPOs that I'm involved with, but sadly the answer is a firm NO until 1st class threading (like Flowdock, unlike Slack) is implemented. 1st class threading means each message can be it's own thread, and each reply has all chat features available. Slack screwed this up, you can't add attachments to thread replies etc.

[sunjam]

Hi, I just want to say that I am also evaulating Riot for an organization... this feature is critical in making the move to this cool software. I'll certainly be watching for updates. Cheers

[joshfleming]

Also, adding my experience, that when trying to convince groups to use Riot instead of Slack, threading was sited as the reason to stay with slack. And I can't disagree, noisy topics can be a real pain. But I'd really like to move to an open source option with end to end encryption like Riot

[andrewperry]

metoo

[vlcek]

For our organization is also a very important feature. Without it is almost unusable for us.

[ptman]

I've heard a lot of good about threading in Zulip, but it might be hard to implement in Matrix due to the focus on rooms instead of topics

[MurzNN]

Yes, Zulip is interesting solution for threads in chat, but the problem that topic is obligatory field - this is not hard to implement, but this will got problems for people with free chatting (offtopic chats). Maybe good solution will be do this feature at per-room basis, to require all messages with topic only on specific rooms.
But as for me - Slack implementation of threads is more useful for base functional, because we can convert already posted message to thread, missing feature is only group/move several already posted messages to the thread.

[smacz42]

I'm surprised that no one has pointed to Microsoft Team's implementation of threaded conversations. It's nothing to write home about, but it's good to have to keep different conversations separate.

Just wanted to point out another competitor that has that implemented.

[dessalines]

So far mattermost has this down .

Has there been any movement on this?

[ptman]

someone is working on replies, is it @t3chguy ?

[t3chguy]

Yup, https://github.com/matrix-org/matrix-react-sdk/issues/1741

[andrewperry]

Exciting, almost there! Thanks!

Andrew

On 27 Apr 2018, at 7:09 pm, Michael Telatynski [e-mail] wrote:

Yup, matrix-org/matrix-react-sdk#1741

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[ghost]

In my opionion the last missing Riot feature preventing slack users to migrate to Matrix/Riot.

Looking forward, thx to all devs working on this!

[ghost]

Could also use this feature

[yann-soubeyrand]

In my opinion, Twist has the best UX in this domain.

[eras]

Just one data point: I use weechat with wee-slack to Slack and wee-slack's support works like this: you enter /thread abc where abc is a generated thread id that is visible next to existing thread beginnings in the screen. The command makes that thread to appear as a "sub channel" in the channel list (ie. right below the parent channel, in a lower level of hierarchy) and works similarly to all the other channels.

You can close (remove from the list) and re-open them again according to your interests.

This "view thread as a sub channel" in my view is great feature that Slack as well could have, as it enables following even old threads and seeing activity in the interesting ones more easily. I believe many threads in Slack die not because the subject matter has been handled and interest diminished, but rather because it's practically impossible to attend multiple threads with it.

Perhaps the thread feature of Riot could have a similar functionality, in addition to how they are currently being designed. It would probably be a button like "attach to channel list" but with a much more succinct label or icon :-).

[dessalines]

Why have two panes? It might be possible to just do reddit / flowchat style:

[t3chguy]

That's not threading fwiw, thats nested replies. The order of the two green ones is completely circumstantial

edit: (they're ordered based on time and not directly related to each other)

[t3chguy]

(and doesn't work very well when reversed like for chat)

[t3chguy]

and as you can even see on that example its unclear what came first between the tiers of replies, you have to read the timestamp. Whereas in threads things happen in a determined order, here its harder to follow

[dessalines]

Not really understanding this one. How is threading different from nesting? You're replying to specific messages. The order of nested replies could be bottom=recent, just like the matrix chat window currently is.

How does a 3 or more deep "threaded" reply look?

[t3chguy]

Threads are not direct replies to their previous, they're like a sub-room based on an initial forking point

[ptman]

In what context? Since when? Threading in email since before I was born is quite like the threading in reddit: http://www.davep.org/mutt/screenshots/index.png

[t3chguy]

right and it doesn't work very well when you flip the table and look from a leaf as you would in a messenger

[dessalines]

So if I'm understanding you right @t3chguy , you're under the impression that "threading" means a max depth of 2, while nesting means unlimited max depth? Email is considered threaded, and it has unlimited max depth.

[t3chguy]

not explicitly no, Email is considered threaded yes but implementing that style of threading in real-time chat such as riot, slack etc is considered by many not good UX

[dessalines]

I mean, I've already coded an example of this working with websockets, here's an example.. Live-updating, threaded messaging. But I'd love for matrix to have this too.

[t3chguy]

implementing threads in matrix by each event including every event that preceded it would be poor, better design would be a forkable swim-lane style approach imo

[smacz42]

FWIW Email is an asynchronous method of communication, while chat is widely regarded to be a synchronous method.

The requirements and workflow of chat are therefore different from email, which this type of "sidebar" threading lends itself to.

Which is not to say that allowing multiple "forks" would be a bad idea. I would love to see a mockup of that.

[t3chguy]

@dessalines nice example, but typically in a real-time chat application people want to see the latest thing said at the top/bottom of the viewport to see whats being discussed right now, not have to find the trunk of the thread to be able to see what the latest thing was said in it

[dessalines]

In the two-pane, max-depth = 2 model though, the most recent messages also are not at the bottom... In fact, you don't even see them until you click the thread, so it makes them far worse than the reddit / email style threading.

[t3chguy]

The latest messages would be at the bottom of the left pane?

[t3chguy]

I'm not saying reddit style is bad. It has much higher data density and vastly different priorities.

[timeandtimeago]

Any update on when we can expect this functionality to start rolling out?

[dessalines]

I think its been implemented... the replies, and comment chains expanding on click are working now.

[ajvsol]

It's mostly there but there's a few improvements I'd like to see:

1) One-click thread view

This is the current method of opening a thread:

It would be useful to have a one-click button that can open all replies in a thread instead of repeatedly click "in reply to".

2) An overview page of all current threads

e.g. Slack's "All Threads" page

3) Room setting: threads-only or threads-optional

Twist and Zulip are good examples of chat apps which force all messages to be in threads. For most large chat rooms this would result in a thread for #general and maybe an #offtopic, plus many more transient ones for side conversations that come up.

The threads-only approach keeps topics much more organised, because if conversation heads in a specific direction the participants is prompted to move their conversation e.g. from the #general thread to their own one.

In a threads-optional paradigm e.g. Slack or Mattermost, I find conversation to be far less organised and moving chats into threads happens less frequently because there's not the same reminder that conversation should stick to being on-topic.

As Riot is looking to be flexible tool for everyone to use, having the option to have a threads-only room would suit users such as myself who prefer it.

[gerroon]

Is this implemented as of now?

[ghost]

I also can't find how to use the feature - is there some doc in which version it is available and how to use it @dessalines ?

[dessalines]

@p-thurner click the side dots, then reply

[dkasak]

Apart from @neomodern's excellent suggestions, it would also be great if the threads could be named (which he touched upon but not mentioned explicitly).

[gerroon]

Reply does not exists on Android, btw.

[aaronraimist]

@gerroon it does, it is just hard to find. Tap on the message you want to reply to and you'll see that the placeholder text in the message field changed to "Send a reply"

[dkasak]

Hard to find and very easy to trigger by accident. I've had it happen personally multiple times and had several friends complain about it.

[dessalines]

Should this issue be closed considering this is now implemented?

[aaronraimist]

@dessalines Well it would be nice to get a more slack like threading UI where you can see the thread and the entire room side by side.

[dessalines]

I really dislike that style, for reasons mentioned above, as its not truly threaded since its just a depth of 2. Here's what threading looks like with unlimited depth: .

Matrix has already added a kind of "flip-up" unlimited threading that works really great, so I'm not sure why this issue needs to stay up.

[ara4n]

The current 'replies' feature is useful, but not as comprehensive as the style we want to go for, eventually (which is nothing like Slack or Mattermost for the record, but our own thing). However we don't have bandwidth to work on it right now; instead we're focusing on the redesign, E2E stability and performance. So this bug will remain open. Thanks all for the thoughts & upvotes on it though; it's really useful to gather folks' requirements and expectations for threading here.

[tysonclugg]

The Rich replies feature from https://github.com/matrix-org/matrix-doc/pull/1617 adds the necessary fields for threaded messages, and was released as a part of the Client Server r0.4.0 API.

What work (is being done|has been done) towards implementing the Client Server r0.4.0 API?

[coterzo]

Riot is missing a clear Threaded or Multi-Topic conversation that is super-important for many groups who wish a more structured, organized, on-topic discussion.
How TWIST app implements it, is the best way. See the image below for example.
I think this future will make RIOT modern, comparing to old school endless conversations that most people don't have time to read really, and the important things are missed out.

[ajvsol]

Twist was also mentioned in a previous comment with a lot of likes, it's definitely a UI style I'd like to have the option have too.

[dessalines]

The two pane model isn't that great, it only has a max depth of two. Reddit or email style is much better, infinite max depth, although that model can't be organized by both date and thread at the same time.

[ptman]

https://refined.chat/blog/2019/02/slack-threads-ftfy

[fallerOfFalls]

I've put a $400 bounty on slack-style threads at freedomsponsors. expires in 9 months. I really want this.

[ara4n]

(see https://github.com/matrix-org/matrix-doc/issues/1198 for some spec thoughts on this from ages ago)

[fallerOfFalls]

Some of that sounded cool, but most was too technical for me. Can't tell whether it would also support slack-style threading which doesn't allow for infinite forking. However there is a workaround even in slack: forward the message you want to fork off, back into the channel and there's the new thread. Such an approach could be supported explicitly to match the possibilities of reddit style and Twitter style, but just displaying differently. Though the "display this in main channel" option for every threaded message would need to be added.

[smacz42]

Riot is missing a clear Threaded or Multi-Topic conversation that is super-important for many groups who wish a more structured, organized, on-topic discussion.
How TWIST app implements it, is the best way. See the image below for example.
I think this future will make RIOT modern, comparing to old school endless conversations that most people don't have time to read really, and the important things are missed out.

This is email. They've reinvented email as a way to organize chat messages like... email.

[dessalines]

And worse even than email, since email actually allows for a max depth of more than two:

Both email, and reddit style are better than the two pane model.

Here's a good wiki article on conversation threading.

[kiliankoe]

I'm not sure what the current plans are for implementing something like this, but I just want to add my two cents that deep nesting might not be the best way to go. This style works great for comments on platforms like Reddit, where messages are more persistent and read for months to come, but for instant messaging and (large) group conversations, it's rarely useful to nest arbitrarily deep. Slack's style of single-level-threads has been working rather well for many communities I'm active in, ranging from small groups to hundreds of people.

Having the option of arbitrary nesting might sound powerful, but may be become more of a hindrance imho, specifically regarding the fragmentation section in the link @dessalines just posted.

In messaging systems that display threads hierarchically (as opposed to linearly), discussions can easily become fragmented. Unlike systems that display messages linearly, it is much easier to reply to individual messages that are not the most recent message in the thread.
Thread fragmentation can be particularly problematic for systems that allow users to choose different display modes (hierarchical vs. linear). Users of the hierarchical display mode will reply to older messages, confusing users of the linear display mode.

[fallerOfFalls]

@smacz42:

This is email. They've reinvented email as a way to organize chat messages like... email.

Yup. I've written elsewhere about why this is bad:

Each message in a channel must have a subject, just like an email or a reddit post. This keeps everyone on topic, but it creates an additional problem: Every time you want to share a new thought, you have to think of a subject. People (especially me) are bad at thinking of subjects and it interrupts flow.

[KyleFN]

I've never seen a good implementation of Reddit-style deep nesting working in a popular instant messaging app. Keep it simple and use 1-level depth, a format people already use and prefer.

I think the much-liked earlier suggestion "Room setting: threads-only or threads-optional" strikes the best balance because it allows for Twist-like rooms with the former, and Slack-like rooms with the latter - with both these apps being the most frequently cited favourite threaded chat apps. There's no need to think of a subject title as well with the latter option.

[dkasak]

I agree with 1-level depth being preferable over arbitrary nesting for a real-time chat application. I think it would also be preferable if threads were not inline in the main conversation timeline (at least exclusively). Instead, you should be able to view them as a separate linear conversation/room. This is because threads in most of my use cases could get quite lengthy and permanent so keeping track of them by constantly having the scroll backwards in the main conversation to reach them would be awful.

[ptman]

Even if the arbitrarily nested threads would be present in the data, they can be shown with single-level depth by the client. I believe limiting threading to a given level in the spec would be a mistake.

[dessalines]

Basically the crux of the problem is that it's impossible to show comments by both time ( linear) and thread. If you plopped the entire parent chain of a new comment (lets say with 7 parents) to get the full context on a conversation, at the bottom, then the top parent would likely be older than a top-level comment just before this reply.

The reason I don't like slack's 2-pane version is that it's threaded, not linear, but limited to an arbitrary max depth of 2. Replies to older comments are not shown at the bottom, or as being new. You have to scroll up to see new info. So it gets around the problem by being threaded (but limiting it to an arbitrary limit), and isn't truly linear (since replies to old comments aren't shown as new, even though they might add new important info.)

The only way I could think of to show both of these, is to have two views, one that shows the new comments, and the other that shows the entire context / all the parents for either the newest comment, or one you've selected. Or even better, that context view has the entire chat as a tree, and just scrolls to the correct place in it. Or be able to easily switch between these views, one sorting by new comments, and the other sorting by active threads.

[homebeach]

How about having three views side by side? First view is the main chat, second one contains the threaded messages in main chat sorted by the last reply and third view contains the content of the selected thread.

[AndrewJDR]

I'll weigh in with an unpopular opinion (at least based on my reading of the comments on this issue).

Some non-trivial percentage of people using chat systems think threading sucks and will want to be able to turn it off. Turn it off how, you ask? Let me count the ways... :)

1. Per room, as a room admin.
2. Homeserver-wide, inside of homeserver.yaml
3. A a client user, on a per-room basis (user room prefs).
4. A a client user, on a "my entire account" basis (user account prefs).

For evidence that I'm not the only one that dislikes threading and wants to turn it off, please see:
https://twitter.com/emilstahl/status/1054648816647979009
https://twitter.com/googleninja/status/1019978792180375553
https://twitter.com/_david_lang/status/958690745648545793
https://twitter.com/JirikNovy/status/935870198388752384
https://twitter.com/Liskni_si/status/1085229651688148994
etc.
Or search for: slack disable threading
On google and read around.

If anyone wants my personal exposition on why I think threading sucks, please ask. But given the amount of documented dislike toward threading readily available on the net, I'd rather not spend my time writing about it unless it seems necessary/useful. Please read that in a friendly tone, not meaning to be harsh or abrasive, just trying to save some time writing stuff :)

[AndrewJDR]

Just to define what is meant by "Turn off threads":

Turning off threading should flatten the events such that all messages -- regardless of whether they are part of a thread or not -- are always displayed in chronological order, perhaps with each message having a small icon to look at the entire thread in context in some side-view or whatever.

This ability to turn off threading should not be solely an opt-in by the poster of a threaded message (as it is with slack), it should be possible to do this as a user such that it applies to all threads/messages.

Another way of thinking of this disabling feature would be it behaves something like slack threading with the "Always send to #x" checkbox checked (and uncheckable!) for every single threaded message ever posted.

This article also points out this particular usability issue:
https://medium.com/@brad.robertson/slack-threading-failure-threadfail-977859586d5a
(ctrl+f for "the wrong default")

The final thing I find REALLY awkward about threading (mentioned above) is that new messages in threads don’t cause any obvious activity in the channel they originated from by default. My assumption would be that a public thread within a channel would automatically also keep that channel up to date.
There is a checkbox to do this if you _want_ to, but it’s off by default. Every single user has to purposefully update the main channel to keep that conversation relevant, which generally means _most_ people won’t actually do that.

I agree with what he's saying here, but again I would take this even further -- server admins/users should be able to force this "new posts to a thread update the channel too" behavior even if the user that posted to that thread explicitly opted out of it, because users should have control over how they keep up-to-date with unread activity, and server/room admins should have control over whether they are okay with the reduced participation incentivization that can arise from chat threading.

[fallerOfFalls]

I don't want what you want, but I find this a meaningful contribution. The only thing I would caution against is allowing chat to be viewed differently by different users. If there are messages visible to some but not to others then you get some people replying and others confused because they don't see what's being replied to. Per room settings (admin) would be okay though.

There's another solution to not seeing all new messages (the problem in slack): an option to automatically follow all threads in a channel.

[AndrewJDR]

I don't want what you want, but I find this a meaningful contribution. The only thing I would caution against is allowing chat to be viewed differently by different users. If there are messages visible to some but not to others then you get some people replying and others confused because they don't see what's being replied to. Per room settings (admin) would be okay though.

@fallerOfFalls I think the only way to add threading and still have a totally consistent view of all messages for all users (without pissing of people that don't like threading) is to basically default to the equivalent of slack thread's "Always send to #x" enabled, and don't even allow it to be disabled (And thus don't even show it as an option in the first place). The implication here is that any message sent to a thread will also send that message to the main channel at the same time; Therefore thread reply messages would always "live" in two places within the chat log: The thread that it is posted to, and in chronological order within the main, channel. All thread reply messages shown in the main channel can have a little link next to them to open them in a side panel within the full context of the thread.

Personally, I would be totally fine with this, since it minimizes any disruption to those that dislike threads -- they can just ignore the thread icons, don't subscribe to threads, and never open the thread panel, and go about their business consuming unread items linearly as if nothing had changed.

I believe this should also satisfy those server/room operators and users that do like and want threads, since they can start and follow only threads that interest them, which even I can admit can be useful when a channel's volume is very high. That said, a true thread enthusiast should chime in on this.

[dkasak]

The implication here is that any message sent to a thread will also send that message to the main channel at the same time; Threaded messages would always "live" in two places within the chat log: The thread that it is posted to, and in chronological order within the main, channel.

Actually, one of the main uses of threads I have in mind would be to spin off a thread in a room so that unrelated conversations in the room can continue as before, without interference from the thread. The thread is still logically related to the room and contains all the same participants, which is why we don't simply create a new room, an action that is often cumbersome. This is why the default should not be that thread messages are visible in the room as well.

I think this would be handled if the room before the creation of the thread is logically a kind of thread itself: the "main thread". A separate view combining events from all threads chronologically would be okay. Messages typed while in this combined view should go to the main thread, so users still need to be aware that not everyone might know what they're talking about (for instance, if they're just focusing on the main thread).

[AndrewJDR]

Actually, one of the main uses of threads I have in mind would be to spin off a thread in a room so that unrelated conversations in the room can continue as before, without interference from the thread. The thread is still logically related to the room and contains all the same participants, which is why we don't simply create a new room, an action that is often cumbersome. This is why the default should not be that thread messages are visible in the room as well.

@dkasak My 2c: I don't have a problem with this, but I really think that if what you're describing above is something that matrix ends up having, users should be empowered, via a preference, to say:
"No, I don't want thread replies to hide in little pockets where I can't easily see them in a linear context in the main part of the room, and no I don't want to have to open up a 'followed threads' pane to find these messages.
Aka there should be a user-side "'Always show all threaded replies in main chat" option.

@fallerOfFalls Are you saying that you don't think this should be a user option? If so, I'm curious why? I didn't really understand your earlier explanation of "not allowing chat to be viewed differently by different users", since an individual user enabling "'Always show all threaded replies in main chat" (let's assume the default would be off) would only allow said user to see more references to messages, not more actual messages.
It just comes down to an individual's personal preference of how they consume (mostly unread, but to some extent all) content within a chat room. I see no good reason to disallow this as an option, especially if it's buried in a user option somewhere where novice users are not likely to mess with. Furthermore, if you really don't want it within your organization for some reason, deploy a custom riot build or whatever without the option, or change your HS to ignore the event that changes that option.

[dkasak]

Are you saying that you don't think this should be a user option?

I'm not.

I didn't really understand your earlier explanation of "not allowing chat to be viewed differently by different users" [...]

That wasn't me. I agree this should be an option for users. I imagined it not being a preference in the settings because that's harder to find, but instead something like a tab in the main conversation view called "Unified timeline" or "All threads" or something along those lines.

I was merely noting that there will be some UX tension between users wanting to use threads as completely separate conversation lines (so the main thread is less noisy) and those that exclusively want a unified view, with threads being nothing more than some additional information attached to an event ("belongs to threads T").

As an example, I'm in a casual room with a group of friends (about 15 of us). Sometimes it happens that one of us mentions something which only a few of us are interested in and we'd like to discuss this in more detail. However, we don't expect to continue talking about this for an indefinite time, so creating and joining a new room is not a particularly ergonomic option. We'd also like our discussion to be available to the other room members as well—even though they're not as likely to participate, perhaps they'll see or think of something interesting and decide to chip in. Meanwhile, casual banter continues in the main thread of the room without interference from our new thread.

In my mind, this is the perfect job for threads, but for this to work, there needs to be a way to tune in into "all messages belonging to the room, but not belonging to any of the explicitly created threads", which is what I was referring to as the "main thread" above.

The tension arises when we ask ourselves where messages sent to the unified (threadless) view end up. To me, the obvious answer is "the main thread". But since those using the unified view are able to see messages from other threads interposed with the messages from the main thread, they might end up referring to something from them. Users not using the unified view might therefore not know what that person is talking about.

I don't think this is such a big problem, though. It does mean that unified view users do have to keep in mind that threads exist, of course.

[AndrewJDR]

@dkasak Yep, apologies... I got mixed up, It was @fallerOfFalls that may have suggested there not be an option (but I'm not actually sure so waiting on clarification).

Regarding your other points, I believe I understand your usecase, and might even use it myself in some contexts (e.g. high volume rooms like matrix hq where I ask something and just want to follow replies, so long as there's a preference like Always show all threaded replies in main chat that I can turn on globally on my own user account but disable on a per-room basis for my own user account.

[fallerOfFalls]

@AndrewJDR

Are you saying that you don't think this should be a user option?

Yes - because I think it would lead to chaos. However, if anyone thinks it could work, there could be an option in per-room admin settings to "allow users to view all message threads in channel", and then we see what actually happens.

would only allow said user to see more references to messages, not more actual messages.

I like this idea. I worry that some users might reply in the main channel, unless it's made REALLY CLEAR that not everyone can see those references. But it could work well.
Also if such a thing were implemented I'd want it to be alongside the "follow all threads" option, not instead of. Then people can decide how they want to be kept up-to-date. They could have one or the other or both, or neither.

especially if it's buried in a user option somewhere where novice users are not likely to mess with.

That sounds good actually. If it's buried in "advanced" and the UI makes it clear that it's not visible to everyone, I see no problem.

[dkasak]

Also if such a thing were implemented I'd want it to be alongside the "follow all threads" option, not instead of.

This is a really important point, I think, and it's also what I was trying to express but didn't form the thought as clearly. You need to retain the ability to view just the main thread, even if you usually follow a room in a unified view.

[AndrewJDR]

Yes - because I think it would lead to chaos.

The amount of "chaos" it introduces will be only to the extent that users choose to:
a) Disable threading in their own client AND
b) Reply to the main channel rather than replying explicitly to a thread message

Keeping in mind that users that do a are probably going to be savvier users (since the hunted down an option in the user configuration), if you make it clear in the communities that you manage that you really prefer that people reply to threads to keep things organized in the way that your community prefers to organize things, that should be sufficient to keep chaos introduced to a minimum.

That said, I do think some additional chaos is a worthy tradeoff for avoiding the alienation of users that really just hate threading. In summary, I would urge anyone to reconsider any "Users shouldn't be able to turn off threaded display in their clients because it will lead to chaos"-like views that they may hold, because by allowing users view things the way they prefer, that (probably small) amount of chaos that might be introduced also allows us to avoid souring this subset of users to our communities / chat systems -- as happened with slack threads.

However, if anyone thinks it could work, there could be an option in per-room admin settings to "allow users to view all message threads in channel", and then we see what actually happens.

Just to be clear, If you're saying that option would be on by default, I think that's probably fine. But if you're saying that it would be off by default, I think that would be Very Bad, because in practice most admins will not do this, and we will just end up with a (for me and others, irritating) forced threaded system like slack. I still believe that users (not admins) should largely have control over the ability to view things in a linear non-threaded way vs. threaded way, by changing a user-level option within their client and a set of personal per-room options.

[dessalines]

@AndrewJDR How do you feel about the way riot is currently doing threading (the flip up way)? Seems like at least 30% of comments on big chats like #linux:matrix.org are threaded replies.

[AndrewJDR]

@AndrewJDR How do you feel about the way riot is currently doing threading (the flip up way)? Seems like at least 30% of comments on big chats like #linux:matrix.org are threaded replies.

@dessalines As far as I can see, Riot's current "threading" is basically quotations that are expandable/contractable. I don't really have any big problem with it so far, since it still reads fine linearly. I'm not forced to open a threading pane or follow threads and new unread posts are not hidden in "thread pockets", etc.

That said, it might be good to explore options for keeping the reply quotations from taking up so much vertical real estate in cases when the reply is to something that was very recently posted. For example, the quotation here feels redundant/wasteful, and even hinders the quickness of readability just a bit:

I'm not sure how exactly to address that, but here is a rough idea offhand:
If a reply made to a message that is within x messages ago (let's say 4 for example -- the idea is that you will have very likely already read the OP if it had occurred within this number of messages, since that OP will also be onscreen), default to keeping the quotation for that reply in a contracted/minimal form. In the screenshot above, instead of

Levy
| Daniel
| and even the strings are quite usable
response here

It could instead read:

Levy
Daniel (...): response here

and the (...) is a button to expand the quotation to the full display.

[AxelPuerck]

As a newbie on this topic, I've looked at quite a few different messengers and find the zulip way the best one: Every stream (=room) contains topics, but only 5 topics are displayed in the overview (the topics with recent messages).

If you don't care about topics, you can also display the complete stream by clicking on it and the messages are sorted by time.

Everey stream contains a hello topic and if you view the complete stream by clicking on reply (to compose a new message) this topic is used, so you have a default topic.

I think this is a very clean and concise way.

[AxelPuerck]

In my opinion this resembles the real world: some people get together in a room. To talk about a specific topic a little group is formed (and in my experience there are no subgroups) and you can listen to all conversations (at least you can try) or you can focus on a group.

[d3v0ps]

What about Google Chat Room Threads UI?

[timeandtimeago]

For what my two cents are worth - my organization release heavily on slack-like threading where you can be very organized and structured about your conversations in a particular channel/topic.

For us the ability to sort through information and conversation on a specific thread without interruption from other concurrent conversations is really important for the information capture process.

We have been waiting for Riot to implement a more organized form the threading. We have been watching closely because we want to switch to Riot - but until the ability to have structured conversations exists - we can not.

It seems that the public is split over this. Half must have the limited nesting threading (slack like) and half seem to be very opposed to limiting the number of levels deep nesting can go.
It's the difference between a simple on-going constantly morphing conversation stream and the ability to organize those conversations into actual separate conversations.

as much extra work as it is - I believe that this is a case where both options should be offered as configurable features. If one direction is chosen over the other - either one inevitably alienates a whole base of users.

[kiliankoe]

On what level would that configuration happen though? On a community/room/user basis? And how would Riot represent those threads in both styles? Unfortunately I feel that would make things far more complicated still.

[jans23]

I don't see how configuration should be possible on a user level because in my understanding a "fully threated" mode would include subjects which to hide for some users doesn't sound wise.

[d3v0ps]

Maybe adding something like tagging messages and "default" tags and filterings/groupings could solve one part of the problem

[timeandtimeago]

I think on a room basis would make the most sense. Especially being rooms can be shared between servers. Basically the room admin would configure it.

And it could quite easily be done with metadata tagging without ever altering the chronology of messages.

My point here is that this is a highly polarized debate and going with either side over the other will leave a large user base displeased. This may be an area worth investing in flexibility.

It’s not that one method is better than the other - rather they each facilitate very different kind of conversation. Different groups have different needs when it comes to how conversation is organized.

[d3v0ps]

Another related thing I miss from Slack are "pinned" messages, that help too to highlight content at rooms

[ptman]

@aitorllj93 pinned messages are in riot web labs

[donShakespeare]

@MurzNN

Yes, Zulip is interesting solution for threads in chat ...

Yes, Zulip seems to be ahead of everything else in this department. You can really really get real work done when the topics are just there, like a clickable TOC of a huge book.
With beautiful Slack, I am forced to stay fresh, to the ever auto-scrolling, attention-span-destroying chitchat of say, 600 people. I call it a wild market. Yes, if I pay $$$ I will be able to scroll up 900,000 pixels - 🦀 but I, unlike a crab, am slow in the reverse.

... but the problem that topic is obligatory field ....

actually it is optional - Organisation/Realm wide

At first, my drivel-filled slacking brain was so auto-conditioned scared of creating my first topic. I was so terribly afraid to constrain my banter with a heading. But I did it! And now, I have added to the easily found INDEX/TOC. I almost felt the golden buzzer 🎊 🎊 🎆

I must admit, I missed the flow, the mall-like nature of how all #general channels should resemble, where you are filled with glee, star gazing messages as they are lost into scroll oblivion. Oh! the fresh smell of forgettable new!

... but this will be problems for people with free chatting (offtopic chats). Maybe good solution will be do this feature at per-room basis, to require all messages with topic only on specific rooms.

Absolutely. My cravings for blabbing are still strong. I suggest have an optional admin-managed official Topic/Thread: Banter, per channel. And it can be pinned within said channel.

When Matrix/Riot gets this feature in solid place, as I am sure they will - for devs full of awesomeness (not awefull), can produce nothing short of what is their nature - then, I say, rest assured folks, game over (even if there was no competition)!

all bridges will lead to the Riot Zone
_-Marcus Matrixuslus_

[heyakyra]

Sad this didn't even make it on to the "later still" planning board! ):

https://medium.com/@RiotChat/whats-next-for-riot-web-be48f948c801

[sunshineo]

@fallerOfFalls I made a Github bot and a website similar to the https://freedomsponsors.org/ you are using. The Github bot can automatically add a comment to every new issue with a link to a website that encourages people to add reward. (It adds a link to existing open issues when you install). It automatically comments on the issue and tag people when anyone gives a reward, claim the rewards, and approve a reward. Automatically label issues with rewards so you know what is really important for your users.

I wonder if the owner of this repo would like to try it. It's in beta now, I'm looking for people to give it a try.

[denim2x]

I've started working on this and should have a solution inside of a week; let me know if there's ongoing work here, or anything else I should know about

[carlokok]

Just wanted to add my 2 cents here too. The zulip approach is something to really consider taking ideas from:

• General view that shows all channels and their topics:
  1:
  

• The option to narrow to a specific channels or topic inside chat (only see those); this is currently the only option in riot, where you can see the current channel.

• The option to "select" a chat channel or topic (where the rest is visible but fades)

(Screenshots are from the public zulip)

Inside riot/matrix a a channel could be "no topics" (default for user), "allow topics".
Clients that don't support it could just ignore the topic field in a message.

The zulip approach is great to keep up to track conversations without getting lost in the flood.

[mahurinj]

I don't mean to be annoying but there are 100 comments on this issue (which has been merged from multiple other issues) and yet I have still seen no official plan of implementation of a feature that a large number of us consider a must have before we can move our organizations to riot. I understand that there are other important priorities like encryption and security stuff but when I see news about emojis of all things and no mention of this feature in any roadmap or priorities doc I get a little frustrated. Many of us have been waiting multiple years for what should be a basic feature that (as screenshots in this thread have shown) most if not all major competitors provide. Is this a Matrix level issue or is this a riot level issue? Can people higher up in the dev loop please update us on when we might be expecting any sort of news on this? This is literally a critical adoption feature for seemingly a large number of those of us who have commented here (some multiple times) who desperately want to use your product but can't without this feature.

[turt2live]

It's true that it's not on a roadmap right now, but it was flagged as being important (see https://docs.google.com/spreadsheets/d/1oG-w23j_8wQhtoMU-gM0sq4p6y1HYfUzE62RyqapiVI/edit#gid=0 which lists it as "above-average difficulty and relatively high value"). It is a very complicated thing to get right (within this thread there is a rift on the right way to do threading, and whether it becomes a first-class, second-class, or third-class citizen in Matrix), and we don't want to screw it up.

It is a Matrix-level issue however the UX is most likely to be worked out by Riot. Of course if another client implementation wants to shove the work forward, it can at the Matrix level. For now though, we do not know what we actually want to accomplish with this so have largely held off from working on the API surface too much.

Just because it is not on the roadmap does not discount it as important: we only have so many people who can work on things, and need to balance features like this against multiple teams. For instance, this particular issue hits not only the riot-web team, but also the riot mobile teams, design team, backend team, and spec team. Not to mention the other clients which would want to follow in the spec's footsteps.

As with all issues, sponsoring this is the best way for it to jump the queue. It's how features like edits and reactions have landed earlier despite previously being considered near the tail end of the roadmap.

Although I appreciate the call for concern, please let's keep the remainder of this issue about threading and less about the meta-prioritization of our 3600 issue backlog.

[tysonclugg]

When I commented on this in November 2017, I said that I want thread replies to be first-class citizens such that you could add attachments to replies and such. Many people supported my comment, perhaps buoyed on by one single concern of my comment: _back then_, Slack replies couldn't include file attachments.

I also said that each reply should be able to be it's own thread. However, after reading through other comments here regarding "thread pockets", I've softened my stance. I'd be OK with a restriction on thread depth, especially considering the UX complexity concerns that have been raised. If a future UX guru figures out how solve the thread pocket issue, then this restriction could be lifted. Until then, having a thread restriction in place would be a "good enough" solution for me.

[grinapo]

I'm thinking about something like this sketch:

It's like if I select the root, the bottom looks like it does now. If I select a thread head then the bottom shows that thread from there.

The sketch doesn't show what information shall be visible up or down, or whether bottom part shall indicate thread hierarchy somehow (I'd say "yes" to both, but the image in my head still hazy), but you probably get what I guess I wanted to mean, maybe. :-)

One possible problem is "infinitely deep threads" where thousands of messages are threaded, so I would say threads without branches shall be flattened visually.

The other problem is that matrix is only _eventually_ consistent, so people may reply not to the last message on the same thread, so possibly there will be a lot of dangling leaf msg of the same general thread. And of curse it works only when people actually reply to the last message _automatically_, or to selected message manually, and only _new threads_ are not referring back to the last msg, and this have to be selected _manually_, and not replying.

[Biep]

I think fundamentally, threads and communities should be the same thing - and the same thing as rooms. They are all just "brackets". Below the room level they show up as threads, above the room level as communities, and at the room level as, well, rooms.
Ideally it should even be possible to change what the "room level" is, so that from a large room in which several separate discussions run, one thread could be given "room status" - moving those messages out of the current room and into the new one without any serious reorganisation. Or a room could be given community status, all its threads becoming rooms within that community.
Of course the grouping mechanism should be general - grouping by reply-to would just be a special case. A useful grouping would be "anything not in another group", to create a catch-all room in a new community created by lifting a room.

[smacz42]

So, interestingly enough, M$ Team$ have gotten rid of their threading.

As far as a "I have issue X", the simple reply backtrack seems to work well enough. As was said before, the branching mechanism that works so well in reddit's async messaging might not be warranted in a chatroom.

[Biep]

Oh - and stuff like /myroomnick, /myroomavatar, should work on every level of the hierarchy. So community avatars, or thread nicks would be possible. The /nick and /avatar actions would just be a special case, working on the root of the hierarchy.
Likewise, setting thread/room/community names and pictures would be the same action, only on different levels.
And notifications could be on any level too - often in the "maintenance rooms" (#riot:matrix.org and the like) I am only interested in one or two specific threads.

And it would be great if user could decide which level is a room for them. I might want to join one thread in what others see as a huge room, and see that as a room.

[trosel]

I think what people are truly looking for here is a protocol that allows for all of the following types of communication.

So the key is making threads, replies, and slowdown modes (https://github.com/vector-im/riot-web/issues/10960) all optional settings in rooms. And even better would be the ability to create sane default templates based upon these most common use cases (https://github.com/vector-im/riot-web/issues/10945).

Template examples:

| Template Name | Reply Threads | Reactions | Slowdown Setting | Notification Setting |
| --- | --- | --- | --- | --- |
| Town Square | No | No | Very Slow | No Notifications |
| Organization | Yes | Yes | Slightly Slow | only username and all notifications |
| Clubhouse | Yes | Yes | No Slowdown | only username and all notifications |
| Home | No | No | No Slowdown | Always notify of messages |

[Raph33]

IMO, the best system for threaded messaging is by Stackfield: you can "reply" to messages, which quotes the message you're replying it (what Riot currently supports); but you can also start a "discussion", which becomes its own thread. It keeps the chat pane super clear and easy to navigate. And I find quite interesting that Stackfield supports both regular replies and discussions, so teams and users can get organized based on their preferences.

I'll add that this is by far the most important feature for my team. We are currently unable to make the switch over to Riot because conversations get too messy without threading.

[Biep]

Such starting a discussion would be "starting a subroom" in my proposal. That option would come automatically.

[MarcoZehe]

So, interestingly enough, M$ Team$ have gotten rid of their threading.

Do you have a source for that statement? I still see threading mentioned as a top feature to keep conversations organized in the Teams support articles.

[dkasak]

@Raph33: That's an excellent solution for short diversions, but it would be suboptimal for long-lived threads if you had to scroll back just to find it. So, IMO, there needs to be an additional view where it looks more like a subroom.

[grinapo]

(Just a reminder, that Matrix is not necessarily a Chat Network. It could be used for web forums or even to generate webpage [like using the last message of a thread, which is markdown, as the content of a given page]. Chat may have short threads but slower-running forums may have large amounts of long-running ones, and I'm not sure it'd be optimal to have a separate room for every thread. Also, such threads may be hierarchically organised using multiple levels.)

[carlokok]

Having an (optional) topic in the message data could solve, as clients that support it could allow narrowing down to a specific topic (or highlighting the ones relevant to the selected discussion), like zulip does. Opposed to creating a separate channel every "thread"

[dkasak]

@grinapo: Agreed, though my comment (and this thread, as I understand it) is more about the Riot UI than the UI of other clients or about the server-side implementation. A forum-like software built upon Matrix would best be served with a custom client I think, since Riot is (at least in its present state) very chat-oriented.

@carlokok: Yeah, that could work too and I think it's a nice idea. I don't really care much as long as there is a list of named threads somewhere that allows jumping into them.

[MurzNN]

Creating new subroom for each new thread is too heavy process (new room id, members, states, dag, syncing, etc)!

Why this can't be implemented easier, using current replies and reactions functional? Via reactions we can count number of items in thread, also track current thread subscribers, and via replies we can build list of messages for needed thread.

Looking at Slack, all threads functional implemented as regular replies (like Matrix already have), but replies are hidden in user interface behind "xx replies" suffix in first thread message.

[dkasak]

Agreed. In case I was unclear above, I'll just reiterate that I meant that I'd like to have a more subroom-like interface for longer-lived threads, not that threads should in fact be represented as full-blown rooms on the server.

In other words, I'd like the ability to have a named thread which is not just a separate stack of messages stashed somewhere far up the timeline that I have to scroll back to, but instead something that can be selected in the UI from a list of all threads, which would then switch to a view showing only messages belonging to that thread as if they were a room. This seems implementable with the current reply infrastructure.

[MurzNN]

subroom-like interface for longer-lived threads

Riot already have right sidebar "Notifications" that shows message list, and floating composer in "Edit" interface. So we can reuse those elements for implement "View thread" sidebar, like in Slack.

For bookmarking longer-lived threads, we can reuse https://github.com/vector-im/riot-web/issues/2938 feature (when it will be implemented) for per-user bookmarking, and pinned messages (that in labs already) for global bookmarking.

And real subroom feature will be implemented, as I understand, together with Groups refactoring here https://github.com/matrix-org/matrix-doc/pull/1772

[MurzNN]

spectrum.chat is good example of representation chats as forum-like threads.

[Biep]

Implementing a general hierarchical organisation also helps splitting a large diverging thread into subthreads.

[trosel]

@MurzNN

spectrum.chat is good example of representation chats as forum-like threads.

For what it's worth, I find Spectrum's blend of forums and chat together to be very confusing.

In normal human communication, we just communicate differently when we're posting up a flyer on a bulletin board vs when we're chatting with someone.

Chat is naturally understood to be ephemeral and fleeting. Forums are naturally understood to be more permanent. When I tried Spectrum, I just kinda froze up because the permanence of the chat system made me nervous / feel weird.

[dessalines]

@grinapo 's method is correct. Its impossible to show comments sorted by both time (which must be flat), and threaded (which must be a tree), in the same view. If you want to show both, you'll have to use two views or panes.

Here's an example of how I did this in Lemmy. There's a new comments pane (flat), and a threaded view (tree).

[hramrach]

You don't necessarily need to. There is the option to show threads ordered by the date of the newest (or oldest or whatever) post in the thread.

However, current state of the art for chat is to show posts ordered by date and provide an option to show a post in thread view with related posts for context. That allows both following newest stuff and following a particular conversation.

[PackElend]

So, interestingly enough, M$ Team$ have gotten rid of their threading.

Do you have a source for that statement? I still see threading mentioned as a top feature to keep conversations organized in the Teams support articles.

We use TEAMS at office threading (whereby only one level) is still and properly will be possible when talking in channels. It is not possible when you chat.

This gets me to a different aspect. May I add my thoughts about threading, side chat or grouping.

We may start in the very past. there were chatting tools like IRC clients and simple forums. The right to exist of the first one was to exchange information quickly or just talk, nothing to conserve said things. The latter's right was to conserve to discuss things, searching for solid answer/solution what persists.

Over the decade's technology improved to make either thing more comfortable what led to the rise of here mentioned communication tools or apps like phpBB, discourse or vanilla forums besides many commercial apps.
In particular, the communication tools try to poach in the territory of forum apps, what there never were intend to do by their innermost character. It is tried to preserve information or have long ongoing discussions.

I currently work mainly with Slack and TEAMS, both trying to allow to have separées by either allowing to replay to answer (quoting/one level thread) or split them (side-chats /channels/groups).

For sure that helps to keep the interface clean but it often fails as people often answer by a new reply instead of replying to an existing statement. In particular, in slack people missing that there is a thread belonging to a message, so you are having discussions around the same topic in parallel.
In such cases, I would love to be able to move messages to the right discussion and even make them shown in multiple threads as those parallel discussions tend to go slightly in different directions where some answers are useful in either discussion.
I would think more about the git-tree, where you merge or split things easily without losing context. Such an approach would help to understand how a discussion was started and how it was influenced. May It’s Time We Talked About Tags what can repelace group names, thread headers etc.

The main challenge is still how to find old important content. There are features like staring, pinning and favourites but all these things get easily messy. In slack and TEAMS, it isn't easy to find certain things easily. It is rather frustrating, as their innermost character notifying the user about something which lasts for a short period of time but quite often statements are made what should be conserved for a longer period, in particular, if is aimed to reduce emails.
For that purpose, there should be an integration of a documentation app, to make information easier findable. Discourse describes it well in their blog entry Effectively using Discourse together with group chat but even they are not perfect. I find things in their forums by using google than going through the forum's flat structure what is not that intuitive as may mention elsewhere.

The discussion about flat or threaded is quite extensive
Web Discussions: Flat by Design
Why does Jeff Atwood's Discourse forum software use flattened discussion instead of threaded?
Discussions: Flat or Threaded?
Web Discussions: Flat by Design
...
but in the end, you have to make sure, that if a new participant joins a chat, that he or she can easily see what discussion are ongoing and how they emerged, plus what important things were discussed/decided, to be able to contribute quickly.

[hramrach]

Which all boils down to this: there should be an option to view the post both on its own and in thread.

If you don't allow seeing the thread the context is lost.

If you don't allow view without threading navigating the chat becomes too complex and tedious.

[KB1RD]

@PackElend see https://github.com/matrix-org/matrix-doc/pull/2326. I think the consensus is to allow events to be edited to add, remove, or modify labels that are placed on them. They're basically tags for events. If I understand the PR correctly, this would end up being implemented in two ways:

1. Labels to filter conversations in a room, like Topics in Zulip
2. Threads for events/messages that wouldn't be visible with conventional labels, but would show up as replies to a message, like they do in Slack. This still has the problem of people responding directly instead of to the particular message, but you could always add a label with the correct permission level

The UI/UX for this would be crucial, as you said. Also, feel free to correct me if I'm misinterpreting the pull request :)

[hramrach]

Threads in slack are stupid. Of course people ever reply only to the first message. The other replies are not shown at all.

[zbraniecki]

Threads in slack are stupid. Of course people ever reply only to the first message. The other replies are not shown at all.

That's not my experience. Threads in slack work very well to separate the channel attention span from per-thread attention span for people involved in the threat.

[PackElend]

The UI/UX for this would be crucial, as you said. Also, feel free to correct me if I'm misinterpreting the pull request :)

I reckon you got me the challenge is not get lost in numerous labels. What may help to draw a map, showing interconnections of discussions?
As an example there is e-cars and cars, some answer is relevant for both, so it would get both labels. The map would show where the discussions overlap (nested below automotive as an extreme). Some answers are even labelled by environment, so you could easily jump between discussion without rewriting things (reinventing the wheel).
It is not the best example but may it helps.

[grinapo]

I use my (our) original, already mentioned idea with a different UI approach, to consider:

• The user actually may request a fork of the thread s/he's on. The default view is that the room has its root/main thread and people talk only there.
• If someone want to separate a thread/topic then s/he forks the base thread, create a new topic. People stay on the original thread unless they take action to move to a selected thread. And the process is the same ad infinitum: any thread can be forked, eg. a new thread created, in hierarchical (tree) manner.

This is the same process as already describen in these comments but a different narrative: people are all on the main thread, and they notice a newly created thread and they may choose to move over. I imagine these "thread forked" ("thread cerated") markers as collapsed with a message/new message count visible on the line.

• When they move over to a thread they see the thread as a room, with possibly a top and bottom "return to main thread" link.
• There is the possibility to expand all threads and see the room in whole, but possibly not linearly (since threads are together and not mixed into each others).
• Also there is a possibly a collapse all view where one can pick any threads, including root.

This approach make a distinction between replying to a message and forking a new thread, the latter requiring explicit action from the user. This also suits pretty well the web forum/static webpage display of a room.

And the well thought-out UI is extremely important part of the whole system in case of chat clients (eg. Riot).

[PackElend]

I use my (our) original, already mentioned idea with a different UI approach, to consider:

that matches quite well with the idea I have in mind. It is not easy to describe textually. I reckon we have to wait for the first mockup.

• in hierarchical (tree) manner.

but how to avoid endless nesting?

In addition, it should be possible to pull messages from the original thread into the forked thread as you could miss, that there is a forked thread, as well as allowing to reference or extract (merge) entries from other forks into a fork. Feasibility is suggested by

think the consensus is to allow events to be edited to add, remove, or modify labels that are placed on them.

[MurzNN]

Now in Matrix we already have replies to messages, same feature use Slack as threads.

So for implement Slack-like threads we need only implement the thread sidebar in Riot UI, without any changes on backend! If the message is reply to other message, show button "View thread" that will load in sidebar plain list of all previous replies, and composer window, that will post next reply. If message is not reply - display "Reply in thread" button, that show sidebar with message and reply composer. And that's all, not?

If we implement this in Riot UI, this will be same feature as Slack threads, and more Slack fans will can move to Matrix!

And next step will be improve this UI step-by-step via implementing nested threads, subscribers, and all other wanted features.

[PackElend]

but I would extend it by the functionality to drag in answers posted somewhere else and allow to jump off to those answers posted in anther discussion as e.g. discussed in https://github.com/vector-im/riot-web/issues/2349#issuecomment-554011591.
Personally, I find Slack's approach quite confusing and hard to find answers to a specific post as people often tend to reply in the main channel, causing threads to be torn apart.

[tobiasBora]

Does that mean that it's already possible using the current backend protocol to implement a kind of Forum, by considering messages that "replies to another message" as answers to a given question, and other posts as new questions? Would it be still efficient to do queries, like "I want all questions which are not replying to anybody (i.e. give a list of questions)", or "Give me all the messages that answer to this specific message (i.e. display all the answer of a specific question)"?

[LookitheFirst]

I would much rather prefer a simple version to be implemented now (something like a sidebar, showing a reply chain, like @MurzNN proposed) with the possibility to extend its functionality in the future, rather than doing nothing at all while discussing endlessly about the exact featureset.
This thread now goes on more than three years already and still nothing was implemented. The missing threading is the only feature preventing me from switching my communities to Riot/Matrix altogether.

[PackElend]

to be extended in the future.

if any dev don't block features as described before why not 😄

[Raph33]

I believe Matrix needs to first implement support for the feature on the protocol side, before Riot can implement on the client side. Not sure how soon Matrix will implement.

[LookitheFirst]

I believe Matrix needs to first implement support for the feature on the protocol side, before Riot can implement on the client side.

I'm not sure what exactly needs to be added to the protocol. For simple threading support the existing replies system can be used right now. This could later be extended of course

[dkasak]

On Wed, Dec 11, 2019 at 07:03:06AM -0800, Luca Eichler wrote:

I'm not sure what exactly needs to be added to the protocol. For simple
threading support the existing replies system can be used right now. This could
later be extended of course

Well, one thing a purely reply-based threading system would lack is
thread names. However, support for named threads is actually already in
the works (though I don't know when it will ship).

[barudaret]

Somebody should set up an official poll. There are only a handful of actually different models proposed in this thread, so just have a poll where people vote for which model would get implemented. And then just do that. Can't let a disagreement about how to implement it prevent it from happening altogether.

[donShakespeare]

^^This! I agree ...
... but but, sometimes disagreement means that the issue at hand is rather immensely serious (emphasis on "sometimes"), and thus a just-it-implement-it-already approach would more than likely backfire to the extent a rewrite would become necessary.

Let's just say that threading is something ya wanna implement when first the idea of the chat platform is conceived. Zulip did that! and now they can worry about lesser things and stuff, threading is core business.

The above paragraph is more for my future self.

[ara4n]

We've implemented label-based threading in Synapse; it'll be coming to Riot once we've escaped the current E2E sprint.

[Wouter0100]

Curious to see what's coming! Would also be an awesome addition to - like Hangouts Chat - support rooms where threads are forced. When threads are implemented in the spec, I guess this could be something that could be implemented on only the client side - without making changes in the Matrix spec (although, not sure - just discovered this ecosystem :-)).

For example, see:

This feature is really useful in certain rooms. For example:

• sales, every new thread/conversation is a potential sale
• engineering, every thread a new thing to discuss within engineering
• outages, every thread a new outage

This way, everything is neatly sorted out and you're able to read everything that's been discussed for a certain thing with a topic (e.g. sales). We (or atleast I) come to love this in Hangouts Chat, but the downside in Hangouts Chat is that it's forced on all rooms (except "user" rooms), which may not be useful.

[trosel]

@Wouter0100 For what it's worth, myself and every colleague I work with found that new Hangouts Chat app to be beyond confusing. Nobody adopted it although we tried for a day. Learning curve was just far too high.

I'd recommend sticking with something more transparent and familiar :)

[Wouter0100]

@trosel thanks for your comment. We've been using it for quite some time now (as an early adopter) and we don't really want anything else anymore. I must admit, it is some getting used to - and some colleagues still find it a bit annoying from time to time but because of that my request: to make it for certain rooms, instead of all.

[ashkitten]

i used zulip for a time and its topics were by far the best experience i've had with a chat app. i particularly loved the ability to narrow the scope of what i can see to just one topic, or widen it so i can see everything on a server at once. it made monitoring and keeping up with discussions much easier

[Svarto]

@trosel agree, please don't copy hangout chat. There's a reason google has launched a gazillion chat apps and can't seem to get it right :persevere:

[Wouter0100]

Okay - okay, I don't want to say Hangouts Chat is good - but the forced chat feature is something that they've done right in my opinion and we come to love (and use in a very productive manner). There are enough other things that really suck in Hangouts Chat (integrations, unused space, speed, forced threads on all rooms). Zulip looks okay too, but there it seems that you need to give a topic/slug to a discussion - right?

[ashkitten]

zulip requires a topic, yes, but in my experience it's less of a hassle than you might think, once you get used to it. the great thing about that is you can use a room for many different discussions and seamlessly come back to a thread from weeks ago without losing any context, just by using the same topic.

this also lets someone go off on a tangent without disturbing the rest of the discussion, or use the same room for multiple discussions at once without ambiguity

[Wouter0100]

@ashkitten indeed. Nearly the same for Chat, although without subjects.

[tgr]

Confusingly, the 1.0 release announcement for the Slack bridge claims that it can handle threads. That seems to imply there is some kind threading in Matrix already. Or does it mean the bridge converts Slack threads to some different Matrix feature (like direct replies)?

[grinapo]

@tgr wrote:

the Slack bridge claims that it can handle threads. That seems to imply there is some kind threading in Matrix already.

Messages (replies) can reference other messages, which results logical threads, so yes, there is threading already, if you keep quoting messages (which would be visually disturbing with the current UI). It's a kind of threading but with a lot of inconvenient attributes, including the confusion of displaying it in different clients with different approach.

Or does it mean the bridge converts Slack threads to some different Matrix feature (like direct replies)?

I guess that's a question for the slack bridge: https://github.com/matrix-org/matrix-appservice-slack or namely https://github.com/matrix-org/matrix-appservice-slack/issues/45.

[kiliankoe]

Or does it mean the bridge converts Slack threads to some different Matrix feature (like direct replies)?

That's exactly what's happening in the current implementation. All thread replies are converted to replies to the previous message in the thread on Matrix' side.

[eras]

One idea I didn't notice having been mentioned: for a while I used slack via weechat and I really enjoyed its ability to open threads as rooms. (In fact, it was its only way to read threads.)

If you don't have that, then there should be another good way to tag interesting threads in such a fashion that you can very easily find them. In weeslack it was quite easy to find the relevant threads in the room list, threads being listed below the room they were created from.

[ghost]

I just return to Rocket.Chat because of threads and the not responsive web UI of Riot.

[huguesdk]

has the u.x. from braid already been considered? sorry if it has been, i just didn’t find any reference to it yet.

[ara4n]

hadn’t seen braid before, but that looks similar to the ux which the current server impl would lend itself to

[huguesdk]

i just noticed that one of the “coming soon” features listed on their homepage is “matrix.org integration”. 😀

[madduck]

Chiming in with a +1 here, but also to say that I personally find the Slack way of doing things to be rubbish. It's really easy to miss a reply, and I find it annoying that I cannot look at two threads at once.

I'd like to suggest that threads are everything mentioned so far (p1, replies must be first-class messages, …), and that they can be folded within the timeline, i.e. I can collapse a thread behind the original message (though default would be unfolded).

Replies to messages should not be quoting those messages in their entirety. Rather, there should be a way for users to easily quote only parts, if they want to respond to certain aspects only. If replying to a whole message in a thread, display it as a child to the message. The current quoting is very confusing.

Finally, the ability to pop out threads into rooms, or maybe just into sidebars/windows would be really useful, indeed.

[LKNickname]

+1 on all of the things @madduck said - especially the issue being p1 and the proposed changes to "quoting on reply". Discourse has a really nice way of quoting only specific parts: You can just mark the text you want to quote and a button will appear next to the marked text that simply states "quote". When you press on that button a new text-area for replying will automatically open with the marked text being inserted as quote already.

[youngkidwarrior]

Glad to see this topic is till active. Riot threading would be the difference between Riot being good and Riot being great in my opinion. I manage communities on Riot and often times I'm @'ing replying to 80% of messages. It's poor for productivity.

[numen3]

+1 for me too.
I am currently using zulip hosted on zulipchat.com. Unfortunately zulip doesn't support audio or video calls and the development in general is much less active.
So I would gladly go back to riot (especially on the phone) if it had that kind of threaded channels.

I use it in a very small team (my family) for sharing all sort of knowledge (nutrition, pollution etc...) and I find it very useful: the information feels 'persistent' and organic, in the sense that it grows in time and when you go back to it even after months, it is very easy to 'consume'. In a classic-approach chat it would be hard to go back, even few weeks: information would be fragmented and it would take much more effort to find the context of the conversation.
From this point of view zulip feels a little bit like a forum.

On the other hand, in zulip you can have direct chats and group chats in the standard unorganized way, so no functionality is lost.

As for the need to have a topic, after using it for almost an year, I would say it's not bad, and in time it pays back all the effort put in it at the start. For small and medium teams, usually after some time, the number of channels (streams) will probably stop growing (if categories are well designed) and only sub-categories will be added (topics). It feels like reaching a 'optimal' point, but it of course depends on the number of members and the type of team.

Anyway every stream has a default topic "general" where everyone can write when in doubt, so again, if all the main streams are already in place, there is minimum effort when writing some new message.

One last thing about twist: is basically a 1:1 reimplementation of zulip (functionality-wise) where channel == stream, thread == topic. The main differences are in the interface and integrations.

[gonzalocasas]

👍 +1 here as well for this. Especially relevant in these times of coronavirus-induced remote work!

[hramrach]

I don't expect this will be ready before coronavirus outbreak is over.

That said, I stumbled upon a nice writeup about problems of chat https://basecamp.com/guides/group-chat-problems which is something the threading UX can mitigate.

In light of that I would like to point out that there are at least three chat experiences that I would like to see supported

• small focused chat with few people and messages - you want to see everything here. No way you slice it is more efficient than just looking at the whole
• busy channel with many people - this is where threading is really useful. You need a way to pick out just the one conversation and ignore the rest for the moment
• looking through channels - there might be several reasons to do this - you might want to get general idea of the topics discussed in a channel, you might want to look over topics discussed while you were away, you might be a CM/moderator looking for conversation patterns, you might be looking through a channel with cat pictures that can each stand on their own with little relation to the other posts. Either way what you will likely appreciate is seeing all messages you have not seen so far, probably with some context if there is any.

For small channels or channels with cat pictures with little conversation you probably want to see all messages on their own sorted chronologically. Using threads when there is no point will just complicate navigation.

For channels with non-trivial conversations you most likely want the messages threaded with long already read parts hidden. You probably want to see the first message in a thread, the unread messages in a thread, and a few messages that come before the unread ones by default.

Another thing to consider with threads is quoting. While quoting part of long message is really useful there are some corner cases to consider

• quoting message that is subsequently edited
• removing content authored by a particular user (eg for GDPR)
  which implies that quoting should create a link to the message rather than inserting the text into the edit box, and it should create a link to a particular revision of the message in case it is edited later. There is nothing stopping users from cut&pasting the message once it's publicly available but at least the default way to quote should not duplicate content.

[dud1337]

At my workspace this is a strongly desired feature.

[Neodorant]

So, do I understand right that there isn't a "Thread"-option in RIOT at the moment?

Would be great if one day it will be there :)

[fooness]

Would love to see threads in Matrix/Riot-Web. This will improve communication a rather very lot.

[DeniseBryson]

We are trying to get away from Telegram but without threads there is no real improvement for our chats because it's the endless stream of messages which makes it unreadable.

But I wonder what one should do with bridged messages from Telegram or others.
Can they by turned into a thread as well?
How to send the replies back in Telegram?

[MurzNN]

We've implemented label-based threading in Synapse; it'll be coming to Riot once we've escaped the current E2E sprint.

current E2E sprint seems finished, so hope we soon™ see some progress here

[process0]

+1 Zulip style threading!

[grinapo]

I have been talking with the - very helpful and friendly - Zulip folks, and also tried how their threading work. Also tried Slack in parallel. I am happy to see that I am still satisfied with my original view. :-) I will try to create some mockup, but I'll summarize how I see it now.

• Name threads, and use thread_id.
  
  
  
  • UI should offer default name as the message of the thread head.
  
  
• All threads have a head/parent, and they can be infinitely hierarchical (apart from some sane limits to prevent abuse)
• Tag messages by a thread_id.
• Obviously all messages written with a selected thread would get the same thread_id and also use the message it's replying to as parent in the DAG. Messages (by default) shall not show in whole the original message they're replying to (only an idicator and a link to the original)

The UI can be using/applying these various ways:

• The most simple UI just ignores thread_ids and display messges in chronological order, no thread names visible.

Clients supporting threading features have multiple display modes:

• The default mode shows messages in chronological order, and indicates parents ("quote" or "replying to") by some indicator only if it's different from normal [chrono] order. It may be indent+color code, or just a link to the original, but shall not be shown verbatim.
• The thread mode, if specifically selected by the user, would reorder the messages based on their parents (DAG). I am not already convinced how to indicate new messages to the user, since they would be all over the place. It is not useless but defintely needs additional help from the client to be able to find them.
  
  
  
  • I am considering advising those to handle as "automatic threads" and use the same view as for threads, explained below; it would create collapsed thread links with unread counters on replied messages. Against this goes that it could scatter even the most simple but non-sequentially answered room to hell and beyond, and these conversations may find it hard to get back to the room [top] level.
  
  

Apart from that, my main view features would be:

• The view is either show all messages in a room, or
• all messages in a room with thread_id and all messages in the descentant thread_ids.
• all messages chronologically ordered; message tags are visible (full hierarchy on hover, thread name otherwise, color coded), and message tag links to the thread[-head]
• thread heads have an indicator of a thread available, with thread [aggregate in case of hierarchy] message count, unread count and a link which opens a view filtering that room_id subtree.
• UI should visually group or sperate threads, like create a colored border around messages in the same thread_id, or between messages with different threads; in this case only the top visible box would show the thread name (or full path, depending on the visual space available), refer to thread head if not visible.
• Search within thread names is required
• New messages on thread view get the same thread_id and the last message as DAG parent in normal case, and the message they're specifically replying to if the user does that.
• UI offers the message to be filed under a different thread, or into the main room level
• UI may offer message crossposting ("copy message to other threads/parent" in Zulip), see below.

There are some additional functionalities to be considered:

• re-threading: messages shall be able to be moved between threads (by editing), possibly thread heads, so whole subthreads could be reassigned, reorganised. Zulip asks whether I want to move only one message, or all past messages, or this and future messages, which bascially the three case of selecting what to move: messages or the thread_id.
• crossposting: messages may be member of multiple threads, or "copied" up to the room level (like thread summary). This is also a possible source of abuse, nevertheless a very useful feature.
• links to threads in messages
• thread metainfo (which may be automagically there in the thread head message, but worths a mention), even possibly like thread summary, image, singing unicorn gif etc. (Some people are into such things.)
• parallel panes. Lot of people are asking for this: left pane for the room or parent thread, right pane for subthread. Optionally.
• thread delete: deleting a whole thread, with subthreads.
• deleted thread head messages. It may be possible that a thread head message is deleted but the thread would be kept, some guidepost message is required here to point to the thread.

There are some points up there which may not be feasible or require strong server support, to prevent the client to read massive amount of unnecessary data. Unread counters and thread message counters may be just such points. (Or maybe not, since clients read the messages this way anyway.) Updating these counters with late arriving past messages is probably a fun part as well, but doesn't seem to be impossible.

[Biep]

Threads should definitely be rooms, and rooms should form a lattice - so that one room can be a subroom of another, or of various others. The UI can of course treat threads in a special way, but the underlying system shouldn't.
Having a lattice of rooms means that one can also cross-post in a non-spamming way, by posting in the union of the rooms one wants to reach. The message, once read in one room, will then be read in all rooms.
Since users can define rooms, this allows for a very general focus system: If I want to ignore user X, I simply restrict my universe to the complement of X's messages. Likewise if I don't want to read about Y, my universe will be (a subroom of) the complement of all messages containing Y.
The same system allows for notifications - I define the room of messages I want to be notified for as the union of all messages containing my name, all messages about subject X, all messages in thread Y, and so on - intersected by my universe (so as to avoid being notified for messages I don't want to read).
That way the system is simple, uniform, and fully general - allowing for lots of uses that we don't even think of yet.

[grinapo]

@Biep if threads are rooms it may result a serious performance problem to gather aggregates, lastread, unread and msgcounts, since you basically have to walk the whole database looking for events. I think.

Also it feels to be a performance problem having infinite amount of rooms since the database structure right now seems achieve bearable performance by separate rooms from one another (and completely ignore most of those [which are not needed] in functions and federation).

You seem to basically suggest "not to have rooms" but have one big room with lots of thread heads, some of those we would call "rooms", and others as "threads". I'm not even sure how federation could work this way efficiently.

But.. it's possible that it'd work. Server and client developers could answer this way better than myself.

[dkasak]

Regarding infinitely nestable threads, speaking from a purely UX perspective, I still wonder whether there is a good use case for those. It seems like a bad idea, in the same way as infinite levels of subheaders in a document are a bad idea (it's better to restrict to 2, perhaps 3 levels in special cases). My prognosis is it would lead to a lot of confusion and micromanagement. The ability to fork off a thread from anywhere but all threads living on the top level seems to already satisfy most (all?) use cases in a better way.

Am I missing something?

[Biep]

Being able to do something on the architectural level doesn't mean it must be exposed, and being exposed (see subheaders) doesn't mean it needs to be used.
Levels above rooms would include communities (and subcommunities, intersecting communities, and so on are definitely something one would want), a possible usenet-like hierarchy of discussions, and so on.
Since complements would exist, rooms could by default be set up to be part of each other's complements - achieving the current ignorability. One would have to perform a specific action to get intersecting rooms.

Also, once quantum computing arrives, the algorithm landscape will be thoroughly shaken up. If lattice operations become cheap, all Matrix has to do is remove the restrictions, and it has the perfect database structure for message organising.

[grinapo]

Regarding infinitely nestable threads, speaking from a purely UX perspective, I still wonder whether there is a good use case for those.

Without spamming this issue too much (please come over to #matrix-threads:grin.hu to talk): if there's a large traffic generic room (like "linux") there are various topics which are requested to be separated from the main thread, like "ops" or "programming", but some want to create "perl" or "sorting", others "webserver ops". This results a chaos of threads covering wildly different coverage from one narrow topic to wide-ranging topics. From the organisational point of view it seems beneficial to create a hierarchy where subthreads are visible (and aggregated in) in their parents, eg:

Linux » Ops » Webserver ops » Apache » http2

Where people keep narrow chat at "http2" but people can sit in "Ops" or in "Linux" and still see the chat and can react on.

My current experience is that I am joined in 100+ rooms and it's almost impossible to follow them all, unless I keep doing clicking-patrols regularly.

[maparent]

My experience on threaded models: single-level threads work well for very small groups (2-3 people) or if you don't care about remembering what was said. When many people talk, you need hierarchical threads to know who answered whom. They're a hard requirement for my use cases.

[madduck]

Since users can define rooms, this allows for a very general focus system: If I want to ignore user X, I simply restrict my universe to the complement of X's messages. Likewise if I don't want to read about Y, my universe will be (a subroom of) the complement of all messages containing Y.

This sounds like the way Secure Scuttlebutt handles tags.

[llasse]

more thoughts

As all this is till in the phase of countless possibilites, I wanted to mention maxotronic's comic concept of handling threaded messages ("glue chat") which is a refreshing way of looking at this :)

protocol vs client implication

A new thread_id together with the already existing target_event_id should already enable clients to handle a lot of the thinkable executions discussed here. This would not require restrictions on the protocol side (although clients could enforce them). thread_topic could be optional and might - once filled out - be used as a trigger to handle these thread in a different way (other than "just a reply to a message" it could create e.g. an extra thread-pane / a room-like-display / a clickable message-tree on hover / etc. in the client). I can easily imagine a slack or a zulip clone and even more concepts with this - actually even both "styles" incrementally incorporated into riot and triggered by switches (UIX experts step forward!)

If a certain form seems more feasible for a specific usecase (e.g. treating threads as small sub-rooms or sorting the giant parent-thread-_feed_ in different ways) you would either suggest a specific client to your community or have the one-riot-to-rule-them-all support multiple options of displaying them. The downside of sometimes not having "the best message view" to follow (a) conversation(s) by having to click-scrawl through threads as in the current riot-implemenation might be comparable to not have a threaded-messages-tree in email clients, it might not be optimal but it can still work.

Threads vs rooms

Moving the discussion of threads into the realm of rooms does not seem feasible in my conceptual understanding: a room seems to be focussed on an _collection of people_ whereas a thread is focussed on a _collection of messages_. Further levels of subrooms should be discussed within the redesign of communities (is this the right link? couldn't find a current extensive discussion about this) with a focus on hierachy among a group of people.

Also, some of the related usecases discussed here are again thinkable with a threading-model that serves both concepts: having an aggregation of a lot of threads in one room could be displayed as a lot of different (room-style-)tabs (or even reddit-styled expandable topics) depending to your client(-view settings for that room). Depending on the size of a room / the number of participants and messages this might be confusing to someone not having this view available to follow conversations - but this holds true for any large multiple-conversation.

As a side note: I hold this conceptualization to be important for many other questions as well, e.g. introducing a thread in another room (what has been called "moving") is essentially introducing this conversation/messages that others have had/posted somewhere else - a link to a message in another room appears most appropriate, an intuitive display is yet another challenge for the client.

[Biep]

@llasse:
" a room seems to be focussed on an collection of people whereas a thread is focussed on a collection of messages"
A room is a collection of messages that people can subscribe to, or unsubscribe from. The messages are the constant (even deleted messages stay in a ghosty way). Threads are no different in this respect.

[dkasak]

I wanted to reply yesterday, but didn't have the time and I see now that several points I wanted to make were already made.

@llasse, I think you're on to something. It feels as if there are several separate concerns / use cases here which may be implemented in different ways and we often focus on an arbitrary particular way of solving it. This makes the discussion loop somewhat and causes some talking past each other.

I'd like try to enumerate the basic use cases I see.

1. Threads as topics. The most important aspect of this use case is that the thread has a name (its topic) and that it automatically shares the same members as the room it is a part of with no action required from the members. This is the use case I talked about earlier in this issue.

   This could also be solved via the subroom concept, if it would be implemented in such a way that the subroom is automatically joined by all existing room members upon the creation of the subroom.

   Some people expect an additional view where the messages from both the main part of the room and the various threads would all be collapsed into a single timeline.

2. Progressive filtering of topics. This is like 1, but allows nesting topics inside one another and seems to presume that messages from deeper topics would be visible in topics above them by default. I think this is what @grinapo was talking about.

   There might be some overlap here with communities + subrooms, which should also allow to connect a set of people to a set of rooms and establish a hierarchy between rooms (if subrooms are made in such a way that hierarchies are supported). Seeing messages from a room below in a room above would then be a matter of automatically joining all rooms below some room and displaying all of their messages in a single view.

   In general, this seems to me like it's pretty hard to implement, but I understand the usefulness now.

3. Threads as reply chains. I see reply chains as short, nameless and inconsequential enough that they can functionally and semantically remain a part of the main timeline. Hence, there is no need for an ability to list all such reply chains. What is needed for this is the ability to materialize a reply chain as a list of messages (perhaps as a collapsible N replies button beneath a replied message?). The machinery for this is basically there in the form of replies but there is no UI.

   Perhaps the ability of promoting a reply chain to a topic by giving it a name should also be considered.

Apart from these, crossposting (sharing messages between threads) and moving messages between threads were mentioned, but those depend on (some) of these core use cases being implemented first and seem relatively less important. Seeing as implementing all this is a lot of work, it's improbable that all of this would be handled all at once so I think it's best to leave these as later improvements if there is need for them.

[grinapo]

@dkasak for point 2 yes, but not for rooms but messages. Showing all subthreads is the vital part, partially based on testing Zulip.

It is progressive filtering of messages of the given room. I don't see what would be hard to implement, in the most simple approach the client retrieves all messages and only show the ones with the wanted thread_id set. (Suboptimal, but works.)

(I envision a separate event to establish all metadata for the thread and connect it to a thread_id and also its parent, and the client collects those and builds the thread hierarchy locally. When the user points to a topic the client already know all the descendant thread_ids to display.)

[maparent]

Hello! I have been working on a system (idealoom.org), modeled after web forums rather than chat rooms, where threads are attached to topics after the fact, and can live in many topics. I am interested in interop with Matrix/Riot, because I am interested in ways to classify information from multiple sources. I said earlier I think it's important that we have full hierarchical threading; I think it's also important to distinguish the groups of participants in a thread from the audience (which want to follow the topic without wanting to participate, at least initially.) This can be accomplished through rooms, subscription, etc. There are many good ways, I'm just saying that you should think of those as distinct. In my implementation, topics and threads are very different, and a message can be associated with many topics, though it can only have a simple parent in the threading structure. I have seen systems breaking this with post-hoc thread reorganization, and it's definitely interesting, but I think gathering threads under a topic serves the same purpose without muddling the conversation structure, which people use to orient. As an implementation note: I'm curious why @grinapo feels the need for a thread_id? A message has or does not have a parent. A parent-less message is a thread head. That message's id is the thread_id. Synapse uses postgres, so you can maintain a ltree field for fast threading operators. In IdeaLoom, I use my many-to-many topic-to-message links in a first request to construct the thread query, I got pretty decent performance that way. Happy to discuss more, the issue of conversation representation is essential to an ecosystem of conversation-based tools.

[fkjogu]

The slack design team has published a view into their design journey of their implementation of message threads:
Part1: https://medium.com/slack-design/threads-in-slack-a-long-design-journey-a7c3f410ecb4
Part2: https://medium.com/slack-design/threads-in-slack-a-long-design-journey-1c9b1af652c9

They explored a couple of different UX models, including arbitrary deep nesting. They give some insight why they have settled on linear threading in a sidebar; in combination to an 'All Threads' collection and the possibility to also post specific messages of a thread into the parent channel.

Maybe there are some lessons to be learned from the write up.

[bbigras]

Matrix already supports Zulip style threading via MSC2326 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc232...). We haven't hooked it up in Element yet though (and ideally would do much better UI).

https://news.ycombinator.com/item?id=23843774

[erlend-sh]

Just to provide some anecdotal data points from a prospective Element customer (MeiliSearch):

Our 1st priority for threading UI is effectively a replica of the Zulip threading model. We don’t actually require the “new topic is mandatory” behavior though; we’d be fine with every room having a #general tag that new room entrants are defaulted to unless they manually select a or create a different tag.

2nd priority would be a replica of the Slack threading model. We have built up a user community on Slack, so we would want to keep it going through a bridge. Without support for threading, the existing Slack bridge is not feature-complete for our use case.

3rd and way more distant priority would be a replica of the Discourse threading model.

4th and way way more distant priority would be a brand new approach to threading UI. The prospects are very exciting, there’s no universally superior way to do threading. Different rooms, I.e. different projects, will have different requirements for their communication conventions & UI models to match.

Once either (1) or (2) gets implemented on the client-side UI we will I’m existent become a prospective customer. It doesn’t matter so much which is first; as long as we have one model ready for use, we’ll feel at ease knowing the second model will soon be available as well.

[natrius]

Whats the current status on this topic? @ara4n I get this asked really often and in a channel like #osm-de:matrix.org it would be really nice, because sometimes different people ask questions at the same time and the answers get mixed up. Also, this is, sorted by "Thumbs up" the third most upvoted issue right now.

So, are there plans?

[terehov]

This is actually my final concern that might lean us towards Mattermost, unfortunately

[thomcatdotrocks]

Microsoft recently implemented something in Teams (on web and mobile) which I think is a game changer for threaded chats.

I personally love that it forces you to either start a "New conversation", or reply to a different thread. I know that UX decision would probably bug a large subset of other people, but I just thought I'd drop it here.

[ShadowJonathan]

Off-topic note about Teams: I hate that change, it pads every message in a team-based chat with "reply" buttons and message margins, while some of my teams don't use threaded messaging as all as it's way too much of a different workflow than we do, it's slowly pushing us to use other solutions, as UI starts to "feel less nice" on teams with this change.

They could've easily done what slack did; make everything appear as normal chat messages, but start to pad out the thread messages underneath once someone has actually made a thread of that message.

[tgr]

I personally love that it forces you to either start a "New conversation", or reply to a different thread.

Google Chat has been doing that for quite a while (it has been discussed in some related Matrix issue too but I can't find it now). Some people love it, some people hate it. IMO it works well for small teams who talk about specific work-related issues; I doubt it would work well for a large open channel where people just hang out to chat. So, having it as an option that a channel admin can enable would be cool but I wouldn't want it as the only threading mode in Matrix.

[jtagcat]

Microsoft recently implemented something in Teams (on web and mobile) which I think is a game changer for threaded chats.

I personally love that it forces you to either start a "New conversation", or reply to a different thread. I know that UX decision would probably bug a large subset of other people, but I just thought I'd drop it here.

That's very similar to Zulip, 'forcing' threads. As for the design of adding a reply button everywhere, Zulip has done a nice job.

[LookitheFirst]

Yeah, i think the most sensible thing to do would be to implement a room attribute called "threadtype" or something, where you can toggle between chatrooms, slack like threads and tulip like threads (e.g.)

[jtagcat]

Yeah, i think the most sensible thing to do would be to implement a room attribute called "threadtype" or something, where you can toggle between chatrooms, slack like threads and tulip like threads (e.g.)

Room threads value:

• ~default/automatic - depends on room size, like 'notifications noisy for 2-person rooms, only mentions on rooms with 1k members'~
• off / quote-only - current; always available on any setting, simple markdown (>)

All threads should have a 'broadcast' option (slack's 'also send to #channel' checkbox while replying in threads).

• optional-and-hide - Slack-like; offer thread (default)
• enforce - Zulip-like; show all messages; but visually separate the messages; 'sub-channels' to view/filter only one topic; don't show a text box to discourage unthreaded messages.
• enforce-and-hide - Teams-like; enforce, but hide thread replies, unless broadcasted.

default/automatic should be dropped, setting optional as the default. This way, there are fewer options for the users to understand. When the room reaches x members, prompt the admins to possibly upgrade. This helps the room's health, without overwhelming the admin with options (on channel creation). Teaching (the admins, aka any user) less at first, and more over a longer period results in better UX and more learned.

enforce, and enforce-and-hide should just be enforce. When selected, a checkbox appears: 'Show all replies in threads in the channel.' or alike. This could be an user-side option instead. Leaving us with:

• quote-only (aka none/off, what's currently in use`
• optional (actually optional-and-hide, slack-like)
• enforce (actually enforce-and-hide, teams-like)
  and a user option to 'Expand all replies in-channel.'

[linuxmail]

Hello,

I like the threads from Slack too. I have only since a few weeks a Slack account and saw this and liked it immediately. We have also a lot of conversations inside a room and it's sometimes pretty hard to follow the "red line". We have rooms like "devops / sysops / general / app1 / app2 / ..." and we have often several "threads" inside the room and longer conversations around a question / idea and in the middle there is something completely different, which fits for the room, but not for the conversation.
So, for us ... threading is really cool :-)

cu denny

[drpaneas]

Ever since I used threads in Slack, I cannot go back. It is a killer feature. Talk to your product owner and set a priority -- yesterday ;)

[hex-m]

Element (the company, aka New Vector) acquired Gitter and in the announcement they mentioned:

Gitter has some really nice features which are sorely lacking in Element today:
[..]
Threads!
...and we promise to do everything in our power to preserve and honour these features at all costs

Our plan is [..] to merge Gitter’s features into Element

[jordannewport]

As someone who mainly uses Matrix outside of a business context and doesn't need/want threads for my use case, please make it possible to turn threads off, as @jtagcat suggests.

[rht]

Note that threading already exists on the Synapse (see https://github.com/matrix-org/synapse/issues/2329#issuecomment-625506559), it just hasn't been implemented in Element yet.

[tgr]

Agreed that after trying Slack for a while it's real hard to go back (Element just feels a lot clunkier and distracting before it did before my experience with Slack) and this should be real high on the priority list. Threading is incredibly useful for making discussion on large, messy channels with diverse topics easier to follow, for reducing attention drift (the number of times you need to perform the "do I care about this?" check goes down to a fraction) and for managing notifications.

Also Slack is the market leader and not being able to smoothly integrate with it is a huge huge disadvantage. Technically the Matrix-Slack bridge handles threading (it converts Slack threads to and from Element reply chains), but this doesn't really work: on the Element side, most of the advantages of threading are lost this way (the volume of messages, and thus the mental load, does not get reduced; replying even makes the messages larger), and on the Slack side, there will always be enough Element users who don't understand or remember to use the reply button that threadbreaking will be a constant source of friction.

[madduck]

While I do agree with you that Slack feels more polished (they've had a lot more money to spend), I think you're somewhat comparing apples and oranges. I also don't think Slack is the undisputed standard when it comes to things like threading. I for one find threads in Slack to be annoying, and think Loomio did it much better, by allowing replies to comments to show up in context, but also to move discussions into separate threads when it is appropriate. Let's fix it in Element/Matrix first, properly, and then the bridge can follow.

[ptman]

Note that there is now a threading prototype: https://github.com/matrix-org/cerulean . Show how it's supposed to work instead of telling how others must make it work for you.

[rht]

Note that there is now a threading prototype: https://github.com/matrix-org/cerulean . Show how it's supposed to work instead of telling how others must make it work for you.

That's one of the 2 threading projects. See https://news.ycombinator.com/item?id=25095648. Whether the 2 will compete or complement each other, who knows.

[heyakyra]

Link to live demo seems down, any screenshots available?

[N1N74]

Keep threaded posts and chat replies as two separate things.

For example showing all replies next to the message that displays as popup on-hover and jumps to the point in conversation on-click, similar to 4chan, retains possibility of on-topic conversation lost as unmarked replies in chat; and reserving reddit-like threading to threaded posts forcing replies to be made in threaded view of posts so perceived replies cannot be lost as chat. On mobile, previous button is needed to return to chat message that sent you to its reply.

Ideas building on given example:
Threaded posts can also be hidden from being displayed in room and only in a threaded section for the room where all threaded posts are visible. Finding threaded posts can be made easy without having it be lost in between chat, by having number icon notification of updates on posts. Replies in threaded posts can be referenced in room but clicking on it takes to threadlike-simplified popup view of the comment with infinite upper scrolling of parent comments (original post visible) and chat-like display of child comments with reply option that need not reference it in room as well. Notification for threads can be enabled or have it following only interesting threads. Ability to save/pin threads/comments can also be added. Trees of replies can be turned into threaded posts to continue a conversation as a discussion.
"Silent reply" can be used reply to chat visible underneath it and not anywhere else in chat. Silent replies of silent replies only tags the person as a silent reply underneath the main comment similar to youtube's comments.