Do you see this only for channels where threads have been recently enabled and the client hasn’t refreshed yet since that change? Or also in cases where you’ve refreshed already once since threads have been enabled?
I think we saw something like this not too long ago and fixed it.
Maybe it’s resurfaced? If you update to the latest version of tests-passed now, do you still see the issue?
All our chat channels have been recently enabled.
And I am not sure when or how the users refreshed their browsers. Might be a good idea to force a complete refresh from the system every time an update was installed or the admin changed system parameters?
I don’t know about your users, but I know of the users we have and asking them to refresh might end up with the question whether that is something to eat or not.
Going to install the to the latest version now and ask my test users to watch. Thanks for getting back to me.
Hello! I really like that answering to a comment immediately generates a new thread 
I would suggest to assume that a new comment is an answer to the immediately previous comment. It’s the most common occurrence in a conversation. It’s natural for people to use “answer to” for a comment which is already up in the conversation, but when people want to answer to the immediately previous comment, they don’t use it. From the second a person starts writing in this situation I would assume they want to answer to the immediately previous comment and generate a thread (this will work even if new comments appear so the person do not haves to delete and rewrite). So when people start typing, a line above will say “Answering to (…)”, and if they don’t want to do that, they can clic an “x” right next to that text. This will streamline the process and help to keep the channel clean IMO.
I’m pleased to see that others are taking chat seriously enough to preserve it. It is great that we can now obtain CSV of our chat. It would be even better if this task could be handled automatically as an admin setting. However, it is a step forward.
The impetus and the framing of “chat” has been that it is ephemeral and not worthy of permanent storage. Perhaps it is seen as a way to sidestep the burden of including “chit-chat” in the database? Whatever the original motivations were, it is apparent that people want to preserve the chatter and steps are being made to allow admins to do that.
I’m very pleased by the progress and look forward to it being fully preserved.
I’ll preface what I’m saying by acknowledging something that’s a bit of a truism for anyone who consumes chat-style communication - chat is highly subjective and finding the “right” solution is practically impossible if you’re picking one of the many options.
I tend to put chat threading into two categories: sub-spaces and inline.
Platforms that follow the sub-space format create “pockets” when someone replies to a message and all replies are kept in this pocket, out of view unless someone clicks to join it. People are often familiar with this from Slack and is how I’d classify the solution built into Discourse’s chat feature.
Inline replies keep all responses in the main chat thread and point to the antecedent through a link/anchor. There are two variations on this - with and without quoted text. An example with quoted text would be Discord (which uses an excerpt rather than the full quote) or Messages on Apple devices. Discord used to have unquoted inline replies before switching to their current format. The other example of unquoted inline replies is the Chat feature on Stack Exchange / Stack Overflow.
Both are valid and they have their uses and they each sort of “solve” the problems the other creates
As a Slack and Discord user for several years, I’d argue that the “right” solution is probably the one no dev wants to hear - have both. I’ve found the biggest determiners (for me) of which I prefer are:
All this is to say there’s not a one-size-fits-all (or even most) solution. I went in search of this meta post specifically because I was in a 1-1 chat on another Discourse instance and was surprised to see the choice of threading and really wished I could avoid threads.
Some ideas if you want to consider offering both options:
I think what you have is fine but I’d love to see Discourse consider blurring the barrier between these two distinct methodologies as you move forward with the feature.
Thanks a lot for that well thought out and constructive line of thinking.
We really hear you and most of the points have crossed our minds at minimum a couple of times. I’m fairly confident that as chat is maturing and being picked up more, this issue will be addressed at some point in the near(ish) future.
I think that this could be nicely solved by showing inline excerpts of all threads up to a certain limit. So if there are few comments they will be all readable, and if there are more, some will be readable inline which already gives a quick idea of the conversation at a glance (and the user can enter the sub-space if interested).
This applies to forum topics as well IMO. I want to see snippets of the first and most recent comments/replies all at the top list level for easy skimming. I built and experimented with a similar system and one could monitor multiple threads at once just by watching the most recent few replies continually update. (note: this was a reply to the post above which got merged into the separate post below)
I assume at some point topics and threads will become the same base system. It’s mostly a UX/presentation difference, no? Otherwise we are going to have to duplicate many of the same features and capabilities for both.
We currently don’t have any plans to introduce threads to topics. This is a chat-only feature.
There are plenty of existing discussions on introducing threaded-replies though if you’d like to continue the conversation on one of those?
What I mean is that chat with threads is not much different than a forum with topics. As new features are introduced to discourse we will naturally want many of them to apply to both the forum posts and chat posts, which would be simpler if underneath they were technically the same core system.
I too vow for convergence, I think it’s the most robust long term approach for everything in general, to realize where abstractions of functionalities are the same and thus making them so. For example, I proposed once to consider tags as a form of “meta-categories”.