@pnewell currently there aren't threads. By nature chat is going to be with out threads. This could be tricky to implement. And do we really want to convert real time chat into a forum style?

+1 for @geekgonecrazy

If you make a demo at Flowdock, you can see how they implemented it. It is really smart. It doesn't make it a forum per say, it is just a way to group conversations within conversations.

For our case, we work in support, and there is a constant flow of questions coming in to confirm our products features among reps. So sometimes we have questions and answers coming in at the same time, and it becomes hard to keep track of what answer is related to what question.

Flowdock allows you to reply directly to another message, so the flow of the chat looks the same as rocketchat, but messages that are related show different colored dots next to them so people can track which chat is replying to which chat.

Of course in this example, I am having a conversation with myself lol

@pnewell Interesting.. So it doesn't actually group them inline. Just indicates which post its in reply to?

So if you click on the little colored icon, it takes you to a page with just the messages in that thread. That part of it is not as important to us, but not bad to have either.

I like this idea. what is the UI for choosing if you are starting a new thread or replying to an existing? hopefully there is a way to do it via keyboard, i.e. hit ctrl-R before entering text and it pops up a list of recent threads to choose from, otherwise it is a new thread?

You can sign up for a free account here:
https://www.flowdock.com/

No credit card needed and you can play around with it. To answer your question, every message has an icon that appears when you mouse over next to it that you can click to directly reply to it.

If you don't click this when making a new message, it will start a new "thread"

Indeed threads are the reason why I very much prefer Flowdock over any other chat platform. They really, really make any longer discussions much easier to grasp: properly used threads allow users to be aware of the context of any message without the use of hashtags or other explanations. This is also why they suit organisational discussions so well, where looking back at the discussions later on is much more common than in everyday chit chat.

Perhaps a simple way to at least test out the threading feature could be to just add a field to the message model that contains the id of the message that started the thread. Then all the messages in a thread could be displayed by selecting messages with the same "thread field" value and order them with time stamp.

Zulip does it right imo. Look at this screenshot https://blog.okturtles.com/wp-content/uploads/2015/10/zulip-screenshot-preview.jpg taken from here https://blog.okturtles.com/2015/11/five-open-source-slack-alternatives/

It is still the simple chat I love but you can easily see which context (e.g. "thread") each message is posted in, and see it grouped where it makes sense. Especially for integrations with other apps I think this is a killer feature. We use Slack at work currently (I tried to push RocketChat ;-) but lost) and I can tell you it gets messy fast.

Also I believe the archived messages will one day be a treasure trove once we have a usable AI, and the threads give each message a semantic context - priceless.

@Somantiq @pnewell +1

@Somantiq @pnewell +1

+1 from our perspective this is really a killer feature which every web-based communication tool must have.

Telegram's take on replies is pretty good. It doesn't stick threads in separate sections, but sticks a preview of the message above the reply that you can click on and go back to, along with overlaying a button to return. It keeps the linear ordering but allows for easy following of concurrent conversations.

Anybody got any ideas about how to implement this? I'd love to help but I don't know where to start.

Zulip's "topics" (I believe thats what they call them) and their Dashboard stream are the features I miss very much after switching to Rocket. They make it very easy to have lightweight grouping of messages within a channel without adding much noise or overhead

+1 for threads!

Mattermost has this implemented well too.

+1 for threads

+1 for mattermost implmentation

I would be happy to write code to implement this,

+1 for threads too!

@vikaskedia we take pull requests :smile: feel free to take a crack at it! :+1:

:+1:

This really is a core feature that is enticing our users towards Mattermost, their implementation is excellent.

There's another free open source chat that I kinda like which does it like Flowdock from what I can tell (never used Flowdock myself, but checked the previous comments), hopefully it will help a bit: http://scrollback.io

+1 for threads. implement and you will get higherED institutions on board - hurry before they give in to Slack or Mattermost :)

Just wondering... is this under active development? Can we help? We are long term users of Flowdock, though as an open source company I always prefer to use open source tools where appropriate. Rocket Chat appears to tick all the boxes, though threaded conversations is the #1 reason we've never moved to another chat system.

@peterdalydickson This isn't currently being worked on. We're still trying to determine how to best implement it. If you have ideas, please share. We're looking to get as complete of a picture as we can before implementing this.

Not sure I can add any more to @pnewell's initial post and follow up clarification, and without in-depth knowledge of the rocket.chat codebase I'm not sure I can contribute any worthwhile ideas of how to implement!

Perhaps you could distinguish between 'primary' messages in a channel, and 'follow up' or 'reply' messages?

Every 'follow up' message contains both it's own id and the id of the primary message it relates to.

This way, I can either see all the real time communication happening in the channel, or effectively filter to see just the real time communication that's in relation to the primary message.

Does that make sense?!

This jing video might bring it to life a bit more...

http://screencast.com/t/4slXgL6mu

Worth noting that while threads are ideal we have found that in Slack we have a limited thread implementation via attachments (files, snippets and posts), and being able to apply comments (threaded conversation) to those attachments.

+1 for threads. Mattermost has a good implementation of this feature, and Slack is on it.

+1 for threads

+1 for threads

@mciverza GitHub added the :+1: reaction for a reason. Just press it on the main post instead.

+1 for threads!
I've used Flowdock significantly and recently moved to RocketChat.
Threads are the single thing I miss most.

Please bring this, it would be amazing!

Mattermost have best solution for threads

This is just a rough idea on how to make it happen

on the json object of a message, add a "parentID:messageID" which is the message ID of the parent and a "isChild:Boolean" to avoid n+1 level of discussions (though this is a UX debate, should there be 1 level 2 level n level ?)
Finally maybe a "hasChild:Bollean" to make icons appear only if the parent has childs, which is redondant with the fact that you could find if it does, but would clearly speed up rendering.

On the main channel, check for the above properties and modify the display accordingly

for each message {
  if (msg.isChild == true) {
    //display icon or something
  }
  if (msg.hasChild == true) {
    // display arrow icon, or see messages ?
  }
}

function onParentClick (parentmsg) {
  result = [];
  for each msg in room {
    if (msg.isChild == true) {
      if (msg.parentID == parentmsg._id) {
        result.push(msg);
      }
    }
  }
}

Something along those lines ?

Though, I don't know enough about the architecture of RC, and this is maybe obviously wrong ?

Used Flowdock at a previous company and the thread implementation is definitely something I miss now I'm in RocketChat.

I prefered Flowdock's approach over Mattermost's as it maintains the flow of messages whilst allowing you to narrow focus to a particular topic quickly. The main issue encountered with Flowdock's approach was that it was easy to accidentally start a new thread rather than replying to the one you meant to and at the time there was no way to correct that quickly.

Also +1 for threaded messages!

We often have several conversations going on in the same channel - and very often individual conversations will drown as new messages are posted and new topics are raised. This can also make it very difficult for anyone who has not actively been keeping up with the flow of messages in a channel to both keep up and stay engaged in a topic.

I know this does not help much on the tech side ;-) But thought it would be useful input.

+1 for threaded messages :)

+1 for threads. I'm speaking for an entire company in saying that threads are what has kept us solidly with Flowdock, despite trying to move over to Slack multiple times because it's supposed to be better/hype/out-of-the-box integrations. Assuming that synchronous messaging shouldn't have threads is like assuming there's only one conversation going on in a physical office space at any one time.

We want to use rocket chat as our internal communication tool
but we need threaded communication as we have lot of support request
which need to follow up and we want user to comment and once done
we can close it in chat system we are not able to follow up properly
currenly we have mixed of chat + forum

Rocket chat is perfect for us if threaded communication feature added to it

Appreciate rocket chat team for very use full open source software

+1

https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd#.jseyendl4

Please don't implement threads. Slack's threads suck. I'm pretty sure the obsession with threads is a false consciousness. And however you implement threads, half of the people who want them will hate your implementation.

If it were implemented I think it should be done as an optional component. Not every group needs this but it's a nice to have for development groups. I might suggest this down to a channel level option, not just an administrator level one.

@lukerohde Really if you have nothing useful to contribute, just stay out. This is clearly a thread promoting implementing thread functionality.

@everyone-else, please don't feed trolls.

Yep I was trolling. Sorry. We want to move off slack on to Rocket.Chat so we can roll out chat more broadly. The only thing holding us up are a few of us who think we need threads. I don't agree as we've found slacks threads really interrupt conversation and make things hard to follow. It's frustrating.

The consensus amongst the thread lovers is flowdock's approach is the way to go. But this is basically just coloured tags. Message tags would have other utility and could serve a similar purpose. I hope this contribution is more constructive. And sorry again for being a jerk.

@KptnKMan it is perfectly reasonable to offer a dissenting viewpoint in a community discussion. Please treat people who might not share the same viewpoint with the respect they deserve.

@brylie I was perfectly respectful of his opinion, and I honestly think you should read back over his first input. He had nothing useful to add, and and I was being directly honest about that.

There is nothing wrong with what I said.
This is a feature request thread.

Update: Just wanted to add, I really agree with the followup explanation from @lukerohde
I have also recently switched from Flowdock to Slack, and the implementation of Flowdock's thread is much much better, simpler and less distracting. 👍

+1 for implementing. Very much needed! Would be nice if it could be taken out of the channel conversation somehow so it can continue like a normal chat and not overwhelmed with replies.

+1 on Flowdock type approach to replies. Keeps room clean of clutter to easily find different topics going on throughout the day.

Just heard a podcast discussing how threads actually aid bot interaction in slack, because it lets the bot interact with the human in a thread instead os spamming the whole channel.

@liorkesos could you provide a link to the podcast?

It was in the prielly bot podcast..
Not sure which chapter (I was binge hearing them ;) )
Probably one of these..
https://www.oreilly.com/ideas/amir-shevat-on-enterprise-workplace-communication
https://www.oreilly.com/ideas/ben-brown-on-bot-tools
Found this as well
https://api.slack.com/docs/message-threading#best_practices

I'd like to second the objection above by @lukerohde to Slack style threading. I'm on his Slack team, and can confirm the friction it's caused. I'm a big fan of threading, but Slack's thread implementation is bizarre, if you ask me. I started using it on the grounds that it was better than nothing, but it gives you a choice between hiding your replies where lots of people won't see them, or posting very cluttered looking thread reply announcements into the channel.

I haven't tried Flowdock, but I like the look of the screenshots posted above. Coloured tags seems like a good compromise.

But where I've seen many threading implementations fall down is where some users forget or refuse to use them , or misuse them. Ie a threaded conversation might be missing several replies that people posted unthreaded. Or someone will accidentally post a new topic as part of an existing thread.

If you implement the tag style "threading", I think it would be helpful if the tags could be edited later to fix incorrect/missing threading - not just by the message authors, but by an admin. The aim in my case would be that every conversation would be properly threaded so they can be useful as a knowledge-base, instead of scattered among several competing conversations.

I've been using Rocket.Chat for about 10 minutes, but it looks to me like Reactions are halfway there to Flockdock's coloured tag "threading". Would need to add:

• some solid coloured emoji's added to the library
• an easier way to add them than via the Reactions menus
• a button to "reply", which would automatically copy the relevant emoji to the new message (and add one to the original message if it hasn't already got one)
• maybe some navigation or filters to help users see the threaded conversation (some conversations could restart months later, and you'd still be able to read the whole conversation)

Doing it that way means users could adjust the threading afterwards, moving messages in and out of threads as they see fit. It's just tagging really, without the tags actually having any meaning other than than to identify parts of a conversation.

May I ask... How is the status of implementing threads? O:-)
My team and I used it a lot in Slack.

I'm with the guys above. Threading is not too useful at all and just serves
to annoy people.

I'd much rather effort be put into rich messages as slack is accelerating
at lightnings pace in that area.

Things like interactive messages and messages with buttons / fields that
can be clicked.

On May 30, 2017 1:27 AM, "Creanimo" notifications@github.com wrote:

May I ask... How is the status of implementing threads? O:-)
Me and my team used it a lot in Slack.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-304686921,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA1QDy76f8v_QbtfZt0G6VaThqsl9U2Mks5r-uP8gaJpZM4GPgO-
.

Hmm I actually liked threading in Slack because the reply function clutters everything with repeated messages. If you have three conversations going on at the same time and everyone keeps pressing reply -
the chat gets annoyingly confusing... while with threads they could neatly retreat in their own little (publicly accessible) space.
And the way it is in Slack you are not forced to create threads, you can still use the reply function. And in Flowdock it's even more hidden. How would that annoy people?

If it doesn't exist you should create an issue for the features you described. Sounds interesting too, but seems to be something very different.

I'm with the guys above. Threading is not too useful at all and just serves to annoy people.

@jszaszvari, it certainly annoys some people, but obviously not all. Can you elaborate on how it annoys you? I think there are compromises in implementation that could work for most people.

I'd much rather effort be put into rich messages as slack is accelerating at lightnings pace in that area. Things like interactive messages and messages with buttons / fields that can be clicked.

Again, can you please elaborate? What do the buttons do when you click them?

Hey guys, do you have some news about threads? That`s the only thing that prevents migration from slack for our company.

ping

I also would like to see threads.

I guess this is not progressing? This is blocker for us.

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.

I agree with others who don't like Slack's threading implementation - it's unwieldy when threads are an add-on rather than being the default mode of chat. In-line channel chat stays the norm and you only end up threading when it's extremely disorganised.

The advantage of Twist's over Flowdock's threading is that it's better for keeping conversations on-topic and organised. In Twist's implementation you can select a title for each thread, which helps to predefine the conversation topic.

This makes searching later for relevant information far easier, as well new members can easily get an understanding of things by scanning thread titles and reading only the relevant ones.

Another advantage is that you won't get notified about channel conversations not relevant to you. It's like a channel within a channel and you can select which participants to notify. This is also an of advantage of Slack's threading style, though it would have worked better if they had done it like Twist.

Looks like a clone to Zulip. This is more the direction I want to go but
still need the IRC backend for my die-hard users.

On Aug 11, 2017 9:42 PM, "Aaron" notifications@github.com wrote:

Twist https://twistapp.com/ from creators of Todoist uses the very
interesting concept of threaded channels
https://www.youtube.com/watch?v=LRUpSYm9Db4:

https://camo.githubusercontent.com/fd73872455c71c64066a7b1b270d5030f4e41330/687474703a2f2f692e696d6775722e636f6d2f775468756f73772e706e67

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

I agree with others who don't like Slack's threading implementation - it's
unwieldy when threads are an add-on rather than being the default mode of
chat. In-line channel chat stays the norm and you only end up threading
when it's extremely disorganised.

The advantage of Twist's over Flowdock's threading is that it's better for
keeping conversations on-topic and organised. In Twist's implementation you
can select a title for each thread, which helps to predefine the
conversation topic.

This makes searching later for relevant information far easier, as well new
members can easily get an understanding of things by scanning thread titles
and reading only the relevant ones.

Another advantage is that you won't get notified about channel
conversations not relevant to you. It's like a channel within a channel and
you can select which participants to notify. This is also an of advantage
of Slack's threading style, though it would have worked better if they had
done it like Twist.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-321957347,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADTxeADkzcQQ-vL_cb91nHsmL9CEF9itks5sXS1QgaJpZM4GPgO-
.

Absolutely +1 for adding threads. Threads make sub-conversations and topic-related tangents much much MUCH easier to follow and prevent added clutter to channels. This is one of the largest drawbacks of using rocket vs slack and something that is clearly holding a lot of people back.

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

I prefer that style of threading myself, but for some reason a lot of people can't stand it. I think they like to be able to just see all the messages, and that's why so many services like Rocket.Chat have evolved without any threading at all.

I think full threading as you suggest is not going to get enough support to ever happen. It's going to have to be a compromise.

There doesn't have to be any compromise at all. There just needs to be the option to have threaded channels for those who want the organisation, as well as non-threaded channels for those who want to see all messages in one stream.

On 14 August 2017 23:08:51 BST, pshute notifications@github.com wrote:

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

I prefer that style of threading myself, but for some reason a lot of
people can't stand it. I think they like to be able to just see all the
messages, and that's why so many services like Rocket.Chat have evolved
without any threading at all.

I think full threading as you suggest is not going to get enough
support to ever happen. It's going to have to be a compromise.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-322323512

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

I'm not sure. We could have a button that switches between threaded and flat view, but that won't necessarily make everyone happy.

One "advantage" of a flat view is that everyone sees everything, so no one can say they didn't see a reply, like they could if it was hidden in a threaded view where you don't see replies unless you open the thread.

It's quite common for threads to drift off topic, and then you can end up with, say, a thread titled "Need to increase disk space" containing a comment about a need for a larger tape drive to match. People interested in tape drives won't see it because they're not involved with disk space problems.

Personally I'd rather deal with that problem than message clutter, but my team doesn't seem to agree.

I guess we could have a configuration option to hide that button and lock the view to either threaded or flat, for those teams where it's an issue.

Edit: I just reread your comment about threaded or non threaded channels. I'd prefer not to have to decide at channel creation time. I'd rather set it globally. I want threading of some kind to be available all the time, I'm only talking about how they're represented on screen.

@pshute I think a good option with your tape drive example would be if rocket.chat had a User Group feature like Slack where you could call out for example @backups_team in the reply thread so that the backups team who is responsible for the tape drives are notified that they are mentioned in the reply thread.

@cmachler Our team is too small for that, so the already existing option to tag a single user is sufficient. But your suggestion probably highlights the problem - the person making the tape drive comment needs to bother to tag someone, and that's not reliable.

Probably the advantages of a flat view over a fully threaded view (visibility vs clutter) vary with the size of teams. Our small team is fine with a flat view until we have several conversations going on at the same time in, say, the Storage channel. Then we need a way of telling which messages belong to which conversation.

In a large team this might be happening all the time, so a fully threaded view wins over a flat one, and you can live with the fact that people will miss some relevant messages. because they would anyway.

@cmachler @pshute I come from a team with about 700 people in it where this is very important to have conversation organizational tools such as this.

A thread-only channel approach is not the correct way to go about this if you ask me, and the reason for that is we use threads to have tangent conversations.

For example, someone posts a news story -- all of that conversation relating to that happens in a thread off of that message.

Another example, someone posts an off-topic question and needs feedback -- all answers and discussion happens in a thread off of that message.

Please don't go down the route of thread only channels. Just have a setting that can be turned on or off for threads in a channel, that would be ideal

Twist that @LeapingDragon mentioned is nothing more than what forums were in the 90s, it's nothing new. That app is just a real time "forum" with a new name.

I agree with @jszaszvari. The current way that you have to handle threading in Rocket.Chat is to quote the message being referred to (or link it) and then make your comment. This is exactly the same as a forum approach, not a chat approach. If you consider how a forum is similar to this, there are boards (servers) with topics (channels) and posts (messages) from members (users). However, the advantage that Slack (and hopefully Rocket.Chat) have over using a forum is the ability to have fluid, instant (ish), conversations with people in a more user-friendly manner than a chat board/forum.

Ideally, a forum should never tangent from the conversation topic, and therefore the original post topic. If a tangent happens in a slack thread, it's fine and fully contained outside of the rest of the conversation. However, a tangent in the middle of a conversation on Rocket.Chat is extremely disruptive and can throw off an entire conversation, like having separate conversations across the dinner table.

Understanding the importance of threads also depends on the size of the team. With a team of 5-10 people, the conversation usually has a single direction and does not tend to break off. With a large team, this happens much more frequently and the thread implementation provided by slack is very useful to keep things civilized.

Currently, it seems like there is a lot of people asking for this to be completed and nobody stepping up to get it done because of the ongoing discussion about how to implement it "correctly". Because of this, I feel that the implementation discussion should be finished and decided in favor of Slack's implementation. This is for two reasons:

1) Rocket.Chat itself is extremely similar to Slack and provides an excellent alternative for teams who wish to self-host a slack-like platform while keeping the functionality provided by Slack itself. Why would it be a good decision to fully exclude or implement differently a feature so appreciated within users of Slack?

2) The other design proposal with thread-only channels is pretty much what exists right now. You have channels for various topics and inside those channels, there is messages and content related to that topic. Implementing threads like this would simply convert channels into forum threads, which is pointless.

Obviously, this has been in discussion for 10 months already. If this is going to become a usable feature, a decision needs to be made first. I am open to any proposals that other have but I am having trouble seeing reasons for the other proposal currently.

@teknogeek, can you please clarify your opinion of Slack's implementation of threads? My opinion is that they tried to compromise between a flat and a threaded approach, and the end result is nearly unusable - the strangest threading I've ever seen. Very hard to work out how it works without doing a few tests. (I haven't looked at it for a few months, so it may have imnproved.)

We moved from Slack to Rocket.Chat mainly because we'd hit the 10,000 message limit, but Slack's threading was the last straw. The internal data structure of it is probably fine, the on screen representation is not. Team's vary in their requirements, but we need something that allows us to see which messages a part of a conversation, but which will also be usable by inveterate thread haters - people who will not read messages hidden in a thread, and who will post independent top level replies to threaded conversations.

With a team of just 4, it's very common here to have two conversations going in the same channel, often with just two people posting all the messages. I agree that that problem gets worse with team size, but I do think it's a problem for even small teams.

If I was to have a go at implementing this (which I can't), I would experiment first with different views of the existing message structures. We already have a reply button, which inserts the URL of the message being replied to. The actual text of that message is only added as a quote at display time (I believe). The presence of that URL marks the message as being part of a thread, and could be used to display the messages in different ways. Eg:

• Slack style: The original message is displayed in the channel, and the reply chain is hidden till one clicks on a new button in the original message. Then the replies are shown on the right hand side.
• Flowdock style: All messages are displayed chronologically as now, but the chain of replies is identified by a coloured background. A different colour is allocated to each separate thread.
• ? style: The reply chain is displayed indented under the original message rather than strictly chronologically.

@pshute i don't understand. That's exactly what slacks threading allows you to do. See messages in different conversations.

Can you explain specifically what makes it unusable? You say it's difficult to work out how it works..yet every single one of your complaints could be solved with a simple user setting.

@jszaszvari, it's stretching my memory, but I think our main problem was that if someone replied to a thread, it wasn't obvious that they'd done so, at least not to everyone. To help with this, we started ticking the box to also send to the channel. That brought back the clutter, and also confused people about where the actual reply was.

The reply it sent to the channel, from memory, had a reply count in it. We initially expected the count to change as more replies were added, not realising it was a snapshot of the count at the time of the reply. It makes perfect sense now, but just added to the confusion as we learned how to use threads.

Our thread haters never opened the threads, but complained about the clutter of the duplicates posted to the channel. I think Slack probably added the "duplicate to channel" option to overcome the problem of people ignoring threads, but it just added to the problem that threads were supposed to overcome.

@pshute I think you should take a look again, they improved a lot since the initial implementation. The count does update in real time now and is not a snapshot.

You should also get a notification if someone replies to a thread that you were involved in.

I actually hated it when it first came out but it's been improved upon a little bit so its actually usable.

On reading through this discussion again, I would like to make the following observations.

Threading should be optional (consensus reached?)

We seem to have reached consensus that threading should be optional. In effect, users should be able to send messages that are not part of a thread. It might be possible for a message to be added to a thread after it has been submitted, in order to keep the channel organized.

Types of threading

We seem to be comparing two thread styles.

Inline threading

Threads are displayed inline, perhaps in a collapsible widget (e.g. a toggle arrow or plus/minus). Examples given include:

• Zulip threaded discussion blocks (screenshot)

Side-panel threading

Threads are displayed in a side panel, perhaps with a 'replies' button to activate the thread. Examples include:

• Slack threads
• Twist threaded discussions
• Mattermost threaded messages

Wireframes needed

We can now create wireframes of Rocket.Chat user flows, based on the threading styles. The wireframes can then be used for a quick vote and further refinement of the idea.

Common ground

One thing the threading options have in common is the reply button. There may be, if we agree, a small step to take forward right away.

Current situation

The Rocket.Chat reply button is currently 'hidden' under a message actions widget:

Proposed change

I propose a small change to make the 'reply' button visible by default:

Rationale

If/when we implement discussion threading, we can most likely use the existing 'reply' feature. This is so that changes to the Rocket.Chat data model will be minimal.

If we make the 'reply' button visible, we can encourage people to use the feature more frequently. If the reply feature becomes familiar and is the basis for threaded discussions, people will more naturally adapt to whatever form of threading is implemented.

Replies will still be optional, so there is backwards compatibility with current Rocket.Chat deployments.

Motion (to vote)

If you agree with the above proposed change, please vote on this comment with a thumbs up. :thumbsup:

If you disagree, please vote on this comment with a thumbs down. :thumbsdown:

Note: since this is a motion, this comment should not be edited directly, to protect the validity of the vote. Any modifications to this motion can be made in subsequent comments.

I propose a small change to make the 'reply' button visible by default:

Sounds good to me. Why are any of those buttons hidden anyway? There's plenty of space to display them.

We seem to be comparing two thread styles.

@brylie, there is a third type - the Flowdock style where all messages are displayed chronologically. Threads are only identified by colouring messages of the same thread the same colour. Ie to read the previous messages of a red coloured message, you have to scroll up looking for other red ones.

It's a compromise that should make threading haters happy, and it's much more usable than it was for everyone else. A "jump to previous message in thread" button on each message would help where the replies are widely separated.

@pnewell has posted a Flowdock sample above, 4th message from the top.

I'd be fine with Flowdock's style as long as you had some sort of way to easily jump back to the previous message, preferably with a preview for messages further back.

IRC has always handled conversations overflowing the normal channel with just hopping over to a new channel (e.g. #foo-overflow for general semi-relevant tangents for #foo), which isn't too bad and doesn't require implementing a whole new "sub-message" system. Perhaps something like associated/sub-channels would work, where they could be easily created and swapped over to as needed?

@bb010g commented 4 hours ago

... and doesn't require implementing a whole new "sub-message" system.

I don't think we need any new data structures for the types of threading being proposed. The Reply button inserts the URL of the message being replied to, and that could be enough to allow messages to be linked into threads, therefore displayed as threads.

Perhaps something like associated/sub-channels would work, where they could be easily created and swapped over to as needed?

Our team needs all replies to be somehow visible in the originating channel, so creating new channels won't work for us unless that happens.

Some kind of hierarchical sub channel system could be handy. Eg. as well as a General channel, one could have General.socialfunctions and General.other, which could be collapsed in the channel list to save vertical space. But that's not threading, it's just a way of reducing the need for threading.

there is a third type - the Flowdock style

Thanks for the clarification @pshute. My apologies for the omission. I probably didn't understand Flowdock threading correctly when I was summarizing this thread.

+1 for flowdock. I like keeping things chronological, then being able to "drill down" to the thread and filter out other conversations. Also +1 for optional-- we can keep default view the way it is now, and allow folks to change to the flowdock model if they'd like. I am not a fan of allowing a message to grow in size every time someone hits 'reply' though, so I do think a change in data structure is necessary (someone offered a parent/child message idea which I think was pretty solid). So +1 on that too. I do believe it would be possible to maintain the current display format and also alter the data structure to accommodate optional flowdock behavior

I am not a fan of allowing a message to grow in size every time someone hits 'reply' though, so I do think a change in data structure is necessary

@gregs007, I'm not sure a change is necessary. When you use the Reply button now, it looks like it inserts the URL of the message you're replying to, not the actual text of that message. It only adds the text of the message at display time. (Check it for yourself by editing a reply.)

The URL could be used as a link to the parent message, allowing for the various forms of thread display, with or without the "quoted" text".

FWIW, and I think it may have been missed in @pshute's description, it is possible to just read the thread in a Flowdock thread by clicking on the "color" of the thread. I actually think this is the best implementation of threading that I have seen so far. I suspect it's also the easiest to implement, you just assign a random ID to each new thread, and if something is a reply to a thread you copy that random ID to the message being typed. Then you can filter on that ID to display just things in that thread.

FWIW, and I think it may have been missed in @pshute's description, it is possible to just read the thread in a Flowdock thread by clicking on the "color" of the thread. I actually think this is the best implementation of threading that I have seen so far. I suspect it's also the easiest to implement, you just assign a random ID to each new thread, and if something is a reply to a thread you copy that random ID to the message being typed. Then you can filter on that ID to display just things in that thread.

@simonv3, I didn't know that. I've never used it, I'm just going on the description of it near the top of this issue. Do you know if there's a public Flowdock implementation people here could log into to try it out?

Adding a thread id should make it easier to implement than my idea of relying on the URLs already inserted by the Reply button, but requires a change in the data structure.

@pshute It's free to try, but you still need to sign up. You can see it in action in their demo video though: https://www.youtube.com/watch?time_continue=31&v=0zrX0cgNTAc (linked is for start time of threading interaction).

@simonv3, I just gave Flowdock a try, and it looks good to me, although I don't like the way it jumps to the thread-only view when you click on the icon to reply to the thread. That would often be useful, but I don't want to frighten off our thread-haters. I'd prefer it it was possible to add the reply in the main channel view.

It also looks like you can't later add a message to a thread. I think that would be really useful, and I found this thread about adding it to Flowdock. It looks like it's a very commonly requested feature that they've been promising for years, but haven't delivered.
https://flowdock.uservoice.com/forums/36827-general/suggestions/3472166-retroactively-change-a-post-in-the-flow-to-a-reply
I would like the ability to add other people's messages to threads. The idea is to "curate" important threads, so we can make sure all replies are visible later when we return to them when similar issues arise. Otherwise there will be missing pieces when we try to use it as a knowledge base.

@pshute Yeah retroactive threading makes sense to me and seems like a generally good feature.

To your first point: I might be mis-understanding here, but when you reply to a thread it still shows up in the main channel view, it'll just have a thread-colored "chat" icon next next to it. People who don't like threads will still be able to follow along on the threads (which is actually why I think this is a better implementation than Slack). At the moment that means that something in the main thread view that isn't linked to a thread isn't viewable in the thread, but your second solution would fix that.

Edit: I re-read your comment and I think you mean that it should be possible to reply to a thread without being in a thread. That seems pretty sensible to me!

The bonus to the Flowdock way of doing it I think is that you can do this pretty incrementally.

What's the down side to changing the data structure?

(Aside: Flowdock also has a general way of tagging messages that can theoretically be really useful, though I've never seen anyone use it).

@simonv3,

To your first point: I might be mis-understanding here, but when you reply to a thread it still shows up in the main channel view, it'll just have a thread-colored "chat" icon next next to it.

What I actually meant was that while you're adding your reply to a thread, by default Flowdock replaces the view of the channel with a view of the thread only. Since then I've noticed that it displays a hint to press Esc+S to see the channel and the thread side by side. That view looks good to me, but to please the thread haters, perhaps the default should be to compose the reply while still viewing the channel only.

People who don't like threads will still be able to follow along on the threads (which is actually why I think this is a better implementation than Slack). At the moment that means that something in the main thread view that isn't linked to a thread isn't viewable in the thread, but your second solution would fix that.

I think this comment from the Flowdock forum I linked to above is very relevant:
It's far too easy to start a new thread, when you actually mean to reply. The way the UI is set up, you're actually *encouraged* to. It's a clear failure in the design, with easily predictable consequences, including users getting angry with each other, but also a fairly simple solution. Just don't make a big text input box at the bottom of the main screen that defaults to creating a new thread! Don't make creating a new thread easier than creating a reply. Require people to either click "reply", or click a button that says "create new thread". This has been suggested several times in previous comments.

What's the down side to changing the data structure?

None if you don't mind changing the data structure. I thought if we could base it all around the inserted links then people could experiment with different displays of existing data more easily. But it won't be me doing any of this.

It's far too easy to start a new thread, when you actually mean to reply. The way the UI is set up, you're actually encouraged to. It's a clear failure in the design, with easily predictable consequences, including users getting angry with each other, but also a fairly simple solution. Just don't make a big text input box at the bottom of the main screen that defaults to creating a new thread! Don't make creating a new thread easier than creating a reply. Require people to either click "reply", or click a button that says "create new thread". This has been suggested several times in previous comments.

To be honest I can't even imagine this happening. I might be using Flowdock in a different way, I dunno, but the issue I experience regularly is having something _not_ be in a thread when replying to a message.

But this isn't really the place for criticizing Flowdock I guess :P

@simonv3, isn't that what they said is happening? People tending to just type their replies into the box at the bottom, rather than remembering/bothering to click the reply icon beside the message they're replying to?

It's worth evaluating the Flowdock interface to see if it would work for us.

I can suggest another approach - Posts.

It is well implemented in another cloud chat application - Ryver App.

Below are some screens:

The main idea is to allow create Posts from chat messages (one or many).
This idea is really great with integration capabilities also. For example, as a dev manager i want to have separate post in channel #dev-urgent for every task with high priority from jira.

I think posts are easy way to go, and can be enabled/disabled per server or per channel.
Best thing is to have a private posts to discuss with another person.

It's far too easy to start a new thread, when you actually mean to reply

I'm not sure 'threads' and 'replies' are so different. If the 'quoted reply' in the message display is just a display time feature, why not:

A) hide it by default while showing the link (and maybe the first line of text) to the previous message.
B) expand the reply (with an option to show all replies to the root?) inline, tooltip, or in a sidepanel.
(tooltip would probably have least impact)

This should appease the 'thread haters' because no threads are actually created, it's just a better visualization of replies. Apparently rocket.chat already follows replies to the root anyways, so there should be no data structure changes needed.

Also, enough bikeshedding already :D

Dear fellows, I believe we can have endless discussions about the visualization of threads, hierarchical rooms, responses and so on.
And I do believe there's no "correct" answer to it. It's much more a matter of personal taste. When it comes down to the model, it's quite similar though: A thread is a composite of messages which might be followed-up on separately.
I'm quite sure that the backend-implementation is the same for all of the above suggestions - whether it's lightweight-threading (the thread has no own appearance, but only in the context of the room it started from) to heavyweight-threading (the thread only appears outside the original conversation).

My verdict: _"Dear RocketChat, please just implement the threads so that they have an own representation (probably an own room with subscriptions). Provide an intuitive way to start a thread (I personally second to https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-322693876) and one visualization. Let community provide alternative visualizations and make it configurable. Configurability and vibrant community are your USPs, so utilize them"_.

I know RC isnt designed to be a replacement of slack, but threads are essential. I agree with the above from Mr Simspon, also why not just give admins and/or the user to the options to decide whether how the threads appear or if it simply shows as a "reply to" like telegram. In slack the user decides if the thread reply also posts in the normal chat as the latest message with a simple checkbox. I dont think it would be too messy to offer some flexibility and options to cover all the the above.

I'm not sure if we're arguing about insignificant details, or what might turn out to be major ones. The most recent couple of messages seem to be saying just do it, we'll work out the details later. If that happens, it's lilkely that whoever does it will do it their way, and some people will hate it.

While it should be possible to come up with alternative representations later, who knows when that will be. In the meantime, some people will be forced not to use the feature, or possible to migrate to another platform. The lesson of the horror of Slack's threading shouldn't be ignored.

+1 for adding threads. I would like to see this feature in the near future.

FWIW my users would get in a complete mess with threading, so an option to disable is a must.

If you are going to do it, then please make sure it is 'Reply Below'. Current reply in 58.2/3 is 'Reply Above' which drives me nuts.

If you are going to do it, then please make sure it is 'Reply Below'. Current reply in 58.2/3 is 'Reply Above' which drives me nuts.

@reetp, I assume you mean the way the quoting in replies currently works. I think placing the quoted text above or below the reply is independent of threading, and should be discussed in a separate issue. A future option to change the order is mentioned here: https://github.com/RocketChat/Rocket.Chat/issues/164#issuecomment-216997224

+1 for adding threads like Flowdock.
There should be an option to disable/enable.

Threads are a must, especially coming from Slack. Once you get a decent number of colleagues discussing things in a channel then it can be hard to catch up, especially when hundreds of messages can occur very quickly.

+1 for Twist type threading

+1 for adding whichever threading model. It would be awesome if someone finds the time to implement it soon!

Would like to see this feature integrated <3

+1

Hi,

I am testing RC for a community of several hundred members. So far, we only miss threads in comparison to slack. Is there anyone on it as it is the most commented issue that is still open and clearly does not lack community interest?

Kind Regards, Quez

I would like this feature too but stuff like this takes time and money to develop (the last update from Aaron, though, is that they need ideas on how to implement this) I think if we want this feature developed we need to put our money where our mouth is (only two people have so far...), which will give more incentive for Aaron and the team to develop it, I don't want it _that_ badly, maybe you do! :)

@Ads20000, perhaps people would like some consensus about how it'll be developed before committing any money. I would really like some kind of light threading, and would pay something to have it. But if whoever develops it decides to do it like Slack did it, I would pay to have it removed.

Given the level of disagreement about how to implement threading, I wonder if it would be better to abandon the idea and just add a message tagging feature (hashtags?). There wouldn't be so much disagreement about how/whether to implement it, and it could serve as a very light form of threading.

I note that someone suggested it here https://github.com/RocketChat/Rocket.Chat/issues/2873, and it was closed because it "doesn't fit Rocket.Chat's architecture".

+1 for Twist like threading...

@pshute People who do not like the idea of threading can just refrain from using it.
I think threading is a great idea and a killer-feature that should be implemented in order to keep rocketchat usable in rooms with higher activity.

@craig I wish it was that simple. What if your team has some who want it and some who don't? If I put a reply in a thread, the people who don't use threads won't see it. Or they'll add replies outside the thread. I want a solution that's a compromise that thread haters can live with.

@pshute It is that simple in most workplaces. This would be something that is enabled or disabled on a per-server or per-channel basis. Generally in the real world, if a team member doesn't like the workflow then their feedback is relayed to the CTO, and if their issue is found to be a non-issue (i.e. personal preference) then it'll be ignored, and if they don't use the company workflow then they'll likely end up fired for not doing what they're paid to do. Simple.

We need threads... How much needs added to the slush fund to get this done?

On Mar 7, 2018 7:03 PM, "Hammy Havoc" notifications@github.com wrote:

@pshute https://github.com/pshute It is that simple in most workplaces.
This would be something that is enabled or disabled on a per-server or
per-channel basis. Generally in the real world, if a team member doesn't
like the workflow then their feedback is relayed to the CTO, and if their
issue is found to be a non-issue (i.e. personal preference) then it'll be
ignored, and if they don't use the company workflow then they'll likely end
up fired for not doing what they're paid to do. Simple.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-371329998,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMcgzNBPve95ETiSUNEGVsh-bHTSnY9Dks5tcHVmgaJpZM4GPgO-
.

@pshute I totally agree with @HammyHavoc to allow enabling or disabling it on a per-channel basis. :)

@craig Yes, it should be possible to enable or disable. I'm not against threads, I want them. I just want a style of threads that will be usable if some users can't be bothered with them much.

@HammyHavoc Do organisations really exist that could force users to use threads? Given how hard it would be to detect and prove deliberate avoidance of threading, I can't believe any attempts to enforce it would get anywhere. I think all you'd achieve would be that people would stop using it altogether. I'd like to avoid this situation by the use of a very "light" form of threading.

@pshute Your comment mentioned a hypothetical scenario in which users who don't use threading will miss information. If someone is missing information and not adhering to the company workflow, I doubt a person would last long in that job.

On 9 Mar 2018, 00:51, at 00:51, pshute notifications@github.com wrote:

@craig Yes, it should be possible to enable or disable. I'm not against
threads, I want them. I just want a style of threads that will be
usable if some users can't be bothered with them much.

@HammyHavoc Do organisations really exist that could force users to use
threads? Given how hard it would be to detect and prove deliberate
avoidance of threading, I can't believe any attempts to enforce it
would get anywhere. I think all you'd achieve would be that people
would stop using it altogether. I'd like to avoid this situation by the
use of a very "light" form of threading.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-371676399

+1

+1

for those desperately looking for some threading ability: In Assistify, which includes a fork of Rocket.Chat, we decided to go for a very heavy threading: Each thread is a room (a custom room type which can have an end). In order to be somewhat compatible also with the mobile apps, we didn't implement any further hierarchical display.
Check this video for a quick overview.

@mrsimpson, that was probably not a big change? Maybe we could try getting it into mainline?

@craig well, one could think so. And the actual changes aren't that huge. With a bit of rework, we could separate it from the rest of our modifications.
However, I've been in touch with the Rocket.Chat-guys for a, looooooong time. I know they've got an own idea how it should work - but it seems they don't make much progress with that, since they want to get it 100% "right".
They also know my solution (recently shared it with @engelgabriel via Skype). Since he didn't ask me to contribute, I expect the only solution to get it to fork our fork. We try to keep a "second-to-latest-release" strategy on our repository ;)

"Done" is better than perfect. ;) Let's hope something happens, I guess otherwise it's time to check out your code. Thanks for the explanation!

@sampaiodiego Feature:planned?

yep. we plan to have it =)

And you'll be assigning a milestone to it?

@mrsimpson Thank you for the video, although I have to admit I found it difficult to follow properly with the messages in German because I couldnt remember which text I had seen threaded and not threaded.

My feeling is that this is not the kind of threading my team wants. It appears to hide the threaded conversation from the rest of the messages in the channel. For us, this will lead to some channel members ignoring the threaded conversation completely, and perhaps continuing it unthreaded in the channel.

For many people, your style of threading is the obvious one, for others, it would be a disaster. I think it is this difference in opinion that has kept this issue going for so long with no solution.

@sampaiodiego can you please explain what you meant there? Do you mean that you intend for Rocket.Chat to have some kind of threading, or that you intend for it to have the threading from Assistify?

@mrsimpson I think it looks brilliant!

Works as I would expect it would. @pshute, if you can cite an example of how threading would work in an ideal world, I'd love to see what your team does want because it may genuinely be superior.

Assistly has a brilliant looking threading feature ready for integration with RocketChat's main repository. Don't like it? Disable it or don't enable it. Simple. Meanwhile Rocket.Chat needs to remain competitive with systems like Slack where threading is to be expected. Let us not forget that Rocket.Chat could easily win over Slack-based teams simply by adding threading.

If employees don't read the documentation or have a workflow explained then it's a failure on behalf of the company utilizing Rocket.Chat within their workflow. If employees that are aware of the feature don't adhere to the usage of it, then that's a problem with the employee, not the system. This is like saying Microsoft Word shouldn't have half the functionality it does because only power users or large businesses make use of it. But really, this is so simple that it's a no-brainer. We have threads of tweets in consumer software, why wouldn't this be wholly logical in chat systems with a lot of users and messages being exchanged?

@HammyHavoc please have a read through the messages above for some of the arguments for and against the various styles of threading. In particular the criticisms of Slack’s threading.

But there doesn’t have to be just one way. @mrsimpson would the data structure you’ve used for your implementation support a Flowdock style of thread presentation? There are screenshots towards the start of this issue. Perhaps it would be possible for teams to select from two or more styles, rather than one or none.

sry guys, just to explain, we're now using the label Feature: Planned for feature requests we really plan to have. So issues of feature requests we don't plan to have on main product will be closed.

we don't have a clear milestone for it yet. but once we have I'll update you guys.

To keep from derailing conversation please see: https://forums.rocket.chat/t/about-the-feature-requests-category/127 for explaination on process change.

Newly launched Google Hangouts Chat for G Suite has the most intuitive implementation for threads. You can either Reply to existing "conversation" or "Create a New Conversation" (new thread).

The one feature that is missing from Rocket Chat. Would be great to implement this in 'Zulip' style.
Easy, handy and helps a lot not to use ctrl+f and lazy loading all the time when somebody wants to find something from the past.
Would be great to collect the topics in categories within a channel, it would increase the productivity.

Backend-wise, all we _really_ need to store is two extra fields, resto, which holds the message ID of the message something is a reply to, and is_op, which is a boolean that simply shows whether a message has replies (is a start of a thread), to allow more smooth and consistent scrollback.

Frontend-wise, we can make it so when you hover on a message without replies, a dot appears. Clicking that dot makes the input field change to the thread's color (can be generated using the message ID), and anything you type in it will be a reply to that message (or rather, the thread that starts at that message). Under the input field, a label will show what you're replying to.

The thread's OP will then persistently have a filled dot and your replies will have a hollow dot, in the same color.

Pressing the dot or hollow dot on any message replies to it. To make a new thread (or rather, a message without replies yet) we can simply have an X next to the label below the input field, that resets it to neutral.

When you hover over a thread dot (so a message that has replies or is a reply), an extra icon appears that when clicked, opens the sidebar to reveal the whole thread.

Furthermore, from the tripledots in the top right, you can see all threads sorted by last reply in the sidebar.

How's something like that? Once I finish my retention policy this may be something I can look into.

Sounds elegant, simple and brilliant.

@vynmera do we need more fields? Currently replies insert a link to the message being replied to, so the hierarchy of messages is already known, they just have to be displayed differently. Your is_op field would be useful, but not absolutely necessary.

How to display them is not obvious. There has been much disagreement about it. I favour the idea of colouring related messages, rather than hiding them away. I'm not sure if a coloured dot or circle would make the threading obvious enough. It might need something bigger.

@vynmera do we need more fields? Currently replies insert a link to the message being replied to, so the hierarchy of messages is already known, they just have to be displayed differently. Your is_op field would be useful, but not absolutely necessary.

How to display them is not obvious. There has been much disagreement about it. I favour the idea of colouring related messages, rather than hiding them away. I'm not sure if a coloured dot or circle would make the threading obvious enough. It might need something bigger.

@vynmera what are you suggesting should happen with replies to replies? Are they the same colour as their parents, and their parents the same colour as their grandparents?

@pshute The reason I'd opt to introduce those extra fields is to prevent extra overhead when loading content - for example, when you are scrolling downward (for example when you Jump back to an old message and scroll back to recent messages), thread OPs would miss details about the fact that they have replies. Whether that's needed depends on the UI, really.

If we want to make the threading more obvious, we could add a message above the post saying "reply to vynmera's thread", in which case we could add a label saying "Reply" which would do the same as clicking the dot.

I'd say the color should be based on the grandest of parents - any reply to a reply is still a reply to the original thread. That way we prevent things from getting overly complicated..

@vynmera es per the model changes: 100% agreed. I said earlier on that any change to the model performed by RC in this minimal way would be appreciated - then, all contributers maintaining their fork could start building their preferred UI on top of it.

As per the UI, some thoughts (independent of the actual implementation)

• We observed people don't really don't care about any structure. They just like to keep on typing in a continuous stream. The UI should reflect that (group messages => yes, but don't take them always off display)
• Notifications for threads have to be somehow separated so that you are able to get informed once one of the threads you "follow" changes (it needs to be a subscribable room)
• You will not stop people from messing up the threads themselves as well. There has to be some mechanism to start a thread from a thread. However, I agree that this might be considered as a thread which has been started from the most-top-level room
• It has to somehow work on mobile as well.
• Colors are a very sensitive thing to users. Introducing more spaces between threads as pictured in hangouts above looks like an alternative at the first glance
  Replying to the thread should be a no-thrills-activity. I can imagine either an input directly below each thread or a button which relocates the message input below the thread.

I think there as an easier approach to provide this thread feature.

Why don't we use (hash)tags like everybody else does? Insta, Twitter etc...
I know the # is taken for the chat rooms, but let's say the RocketChat thread sign is ~
When anybody is composing a message and says:
We should see this ~movie: https://www.imdb.com/title/tt0169547/

This message would appear in the movie thread.

There would be a collapsable list below each channel with the mentioned tags if the user would click on a tag the message thread would be filtered to the messages that contain the ~movie tag.

We'd need a table that would store the tags labels + Id
and a cross-table with relation to between the tags and messages and channels.

This way we don't need to touch the original, default database structure, it would have only a small footprint, it would be more flexible (for example to make it an APP or Plugin), and so much easier to develop it I think.

About the colors: I love colors, but a lot of people gets frustrated by a lot of different colors (too much information). If I'd develop this, I'd add a color field to the new tag label + tag Id table, and this way users would be able to select (or not select) colors to the thread. Easy, flexible, everybody would be happy :)

@csimpi Sounds incredibly messy to me. Slack and similar enterprise chat solutions have pretty much defined the standard for how this should be implemented. Rocket.Chat is copying Slack's "app" terminology too (I raised this point on the forums). Makes sense to go the whole nine yards with it.

@csimpi tags would be useful, but they're different from threads. There's an issue open for tags: https://github.com/RocketChat/Rocket.Chat/issues/7967

Tags are like a never ending thread that runs across multiple channels. If you're discussing a movie, do you want to see all the messages about movies from years ago? Or the other movies being discussed at the same time in other channels?

The use of colours could be configurable by users. You could colour just a symbol in each message, or the use could configure it to colour the message text, or a box around each message, or the message background, etc.

See https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-148425821 above for an example.

@HammyHavoc could you please post a link to the forum discussion about terminology?

@pshute https://forums.rocket.chat/t/rename-rocket-chat-apps-to-rocket-chat-plugins/784/2
There were some private messages regarding the archiving of the thread that were had between myself and @graywolf336.

I just had a look at the threading in Google Hangouts Chat. I could live with that, but I'd prefer "lighter" threading. My preference is still for Flowdock style threading, that doesn't change the display of messages much other than add a coloured icon to indicate which messages are parts of which thread, as per https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-148425821

Telegram solution is the best : simple and useful. replay shows in the same chat whit link to the main message. also messages can categorized using hashtag . hashtags are searchable in group and in all groups.hashtags can be used in customized features such as auto tagging for questions also replay to a question automatically tagged as same question... this is a modern simple useful chat app... threading replay like mattermost is a bad solution for chat app that come from social network commenting with bad UX. in a real time chat app users love chat and replay smoothly in one thread and scroll in one page without interrupt and losing chat location(+powerful search and #)

At this rate I would suggest that threading is relegated to the module
system and independent modules are created to cater to whatever preference
a site owner has.

On Tue, Jul 3, 2018, 7:03 AM asadi110 notifications@github.com wrote:

Telegram solution is the best : simple and useful. replay shows in the
same chat whit link to the main message. also messages can categorized
using hashtag . hashtags are searchable in group and in all groups.hashtags
can be used in customized features such as auto tagging for questions also
replay to a question automatically tagged as same question... this is a
modern simple useful chat app... threading replay like mattermost is a bad
solution for chat app that come from social network commenting with bad UX.
in a real time chat app users love chat and replay smoothly in one thread
and scroll in one page without interrupt and losing chat location(+powerful
search and #)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-402168370,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADTxeJ_lS7N24xsUj5poxwZk24ZNlQbAks5uC3mWgaJpZM4GPgO-
.

right now is there any difference between a reply and a quote, seems like they do the same thing. I was surprised that replying to someone actually quotes them

Zulip has explained very well how threading affects your attention - and how to use topics: (which is a nicer wording then techno-speech threads): https://zulipchat.com/why-zulip/

@rasos that Zulip page gives the impression that they think that's the best way to implement threads. I like their method and I'd happily use it, but it's not always the best way. If it was, we might all be using vBulletin or phpBB.

Sometimes, users want to see everything, nothing hidden in threads. Sometimes they just want to see the messages they're interested in, and they want everything else hidden in threads.

I think we need to be able to switch views so we can see messages as appropriate. Eg threaded/collapsed, threaded/expanded, flat, one thread only.

There is also threading in MS Teams.

You can see them in flat and collapse if not interested.

@stgolem can you please post a screenshot of the flat view? Can you still tell that the messages are related?

@pshute this picture is from google search. I have no access to application.
This is the "flat" view. I mean thread messages are not hidden (as in Slack). But they can be collapsed if not needed.

@pshute your points are valid but being a heavy Slack enterprise user I have grown to appreciate how Slack takes the thread off the main view to keep the main view less cluttered. While most threaded discussions are less than 10 responses it is not unusual to have a threaded discussion with well over 50 responses. Trying to keep these long threads in the main view makes the main view cluttered.

I want to know if there is a thread discussion from the main view but I don't necessarily need to be able to scroll through the thread while in the main view.
Slack has the sidebar that makes it simple to drill into a thread while still viewing the main thread.

@dcberg my main point is that users need to be able to change how threads are displayed. Slack's approach is good in a heavily used channel, but at the cost of users missing some messages because they're hidden in a thread. In that situation they're likely to be missed anyway, so it's the best approach.

In a very lightly used channel, showing messages in chronological order works well. As soon as there are multiple simultaneous conversations, it stops working well.

I've come to the conclusion that trying to find the single best way to display threads is pointless because there isn't one. This issue has dragged on for a long time because we're trying to reach a consensus about which single view to adopt. I think it would be helpful to instead develop a list of switchable views to adopt.

+1 for threads. very useful

+1 for threads!!

Why is this not happening?

Threads for private groups and channels would be such a great feature. It would simplify handling parallel conversations on different topics and reduce noise.

+1 for threads!

One very useful feature would be to set some channels as "thread-only". So the only way to create a message in that channel would be to add to an existing thread or a new thread.

Just like Zulip or Spectrum, this will capture the entire usecase of knowledgebase in chat. If you guys are building threads, then doing this will be a huge value add for community and knowledge building. As someone else said "Real-time messaging with long-term value".

But it can only happen if certain channels are mandatory threads. If you allow mixing of threads and non-threads then it becomes less powerful.

One very useful feature would be to set some channels as "thread-only". So the only way to create a message in that channel would be to add to an existing thread or a new thread.

Just like Zulip or Spectrum, this will capture the entire usecase of knowledgebase in chat. If you guys are building threads, then doing this will be a huge value add for community and knowledge building. As someone else said "Real-time messaging with long-term value".

But it can only happen if certain channels are mandatory threads. If you allow mixing of threads and non-threads then it becomes less powerful.

I like that, but there's still one thing that bugs me: why would 2 be the optimal depth for discussion threads? Maybe we will need to go deeper

First we had only one group chat. Everything was cluttered, so we broke it into channels. Now channels are cluttered so we want to break them into threads. How can we ensure that threads won't be cluttered?

Also, if everything is split into threads, we need to make sure that we can search within the channel and all the other channel-specific features, otherwise that defeats the purpose of having a channel.

@7hibault in the spirit of incremental development and delivery, could you start with a simple one additional level via a thread for any main message. Architect the solution such that it would be possible for you to have nested replies if necessary.

@7hibault have you ever used a true multilevel threading system? I think the last time I did was back when usenet was big. I think I used the Agent client, and it could show the threading as a tree. While it sounds like a good idea, when people have an unlimited number of levels, it tends to just get deeper and deeper. Some people will start the Rocket.chat equivalent of an entire Rocket.chat instance many levels deep, and happily never start a new thread ever again.

Looking at how Facebook works, with posts, replies to posts, and replies to replies, I would say that's enough levels. Any more just allows people to cause confusion. I would argue that if Facebook allowed for quoting, just two levels would be sufficient. Beyond that, people should be starting a new thread.

We already have the basic mechanisms for threading. Using the Reply command inserts the URL of the message being replied to. That alone is sufficient to allow for the messages to be displayed as a thread, with infinite levels if desired. What needs to be decided is how to display them. Currently that URL is hidden, and the URL target message is displayed as a quote instead. It could instead be used to indent the message under the URL target message, or to just colour the two messages the same, or to hide the reply message in the main message list and display it on the right like Slack, etc.

Suggestions to allow/force/ban threads in particular channels can work by just restricting the available display schemes, while still allowing for the Reply command to be used.

We already have the basic mechanisms for threading. Using the Reply command

Hi everyone! IMHO the "Reply" is, a bad thread replacement, like sand is a bad oat replacement. With the answer you copy a quote every time. As a result, useless information (quote) clings to useful information (answer). Of course, useless information may be more than useful information! I would be glad to see the implementation of threads in rocket.chat!

Hi everyone! IMHO the "Reply" is, a bad thread replacement, like sand is a bad oat replacement. With the answer you copy a quote every time.

@atai You're right, but you've misunderstood my idea. The current Reply command does not really insert a quote into the message, it just inserts a link to the message being replied to - you can see this while you're still editing a reply.

After the message is saved, the link is used to retrieve and display the previous message as a quote, but it's still stored internally as a link - you can see that if you edit a reply. As a quote is just of many ways the new message could be displayed.

Another way could be to use that link to identify the new message as being part of a thread, and displaying it as part of a thread.

The user could select from various display modes. One mode could display message links in messages the old way, as a quote. Another mode could use the same links to thread the messages - no more quote clutter.

@atai have you used threads in slack? They don't work like email replies where each reply copies the last message and continues to aggregate the response. In slack the thread feature simply allows you to have a side conversation starting with a message on a channel. It's a simple solution that greatly helps with organizing messages/thoughts within a channel.

I find Rocket Chat cumbersome to use when you have a moderately busy channel.

@dcberg Agreed completely. It's getting to a point with our RocketChat server that we're being forced to consider other options because it's just too chaotic in some channels to follow what's going on. With IM, people tend to write short messages, yet send a lot of them, so it's easy to miss things. A threading option would be a real step forward! :- )

I'm discussing this idea with my team and internally with a rocket.chat dev. Stay tuned, we may be able to push forward with this.

@dcberg I hope I'm not repeating myself too much about this, but Slack's threading is the worst I've ever used. Possibly better than nothing, but I found it confusing, requiring too much effort from users to open threads to read them.

@pshute I wouldn't say that slacks threading model is the worst. :)
It's definitely better than not having any threading model that is for sure.
What I like is that you can take a comment within a channel and have a side conversation organized around the original comment versus the channel itself.
I'm sure it is possible to improve upon Slack's approach but, again, it is better than not having any threading approach. :)

@dcberg the problem I had is that people tended to ignore replies in threads. The only way to get them to see them was to tick the box to put a copy in the channel, which brings back the clutter.

@pshute Slack has an "All Threads" and "All Unreads" option at the top left of the UX.

The "you're up to date" notification that Slack gives when you've seen everything relevant to you is pretty useful. Sure, it could probably be implemented better and improved upon, but some form of threading is superior to no threading, that's a certainty.

Slack also gives you the _option_ to hide channels and threads if they have no new unread activity.

Even _Microsoft Teams_ has threaded messaging. Rocket.Chat seems quite behind on this front.

I also think selecting and adding messages to a thread would be incredibly useful and keep a channel clean, especially if you're troubleshooting a problem that a user or group of users is having, whilst there's simultaneously dozens of other people messaging each other about other things that have nothing to do with it. It can be complete chaos on our Rocket.Chat server.

The lack of this feature is what is making me seriously consider Zulip

Slack has an "All Threads" and "All Unreads" option at the top left of the UX.
@HammyHavoc Yes, but it doesn't help if people won't look at them. My feeling is that threading systems have previously been an all or nothing thing.

vBulletin is a good example of the "all" approach. Every message has to be either a new thread or a reply to one, and threads have subject lines. Very uncluttered, but people who like to skim miss messages with that type of threading.

Rocket.chat currently has the "nothing" approach. Everyone has to see everything, which works well with skimmers until there are competing conversations.

Neither approach works perfectly. Slack went for a hybrid approach, and I feel it makes it even more likely people will miss something important. I've never tried Flowdock's style of thread highlighting, but it seems like a much better compromise to me.

Threaded messages can be displayed many ways, and each way has its advantages and disadvantages, so why not offer a choice?

I also think selecting and adding messages to a thread would be incredibly useful and keep a channel clean

@HammyHavoc I would love that.

@pshute I think it depends what kind of a workflow your business has as to whether threading will be relevant or work for it, though this may or may not work if you run a community-style public server. At our company, we encourage tagging of people, and we do that on RocketChat to attract attention in the UX (it puts a horizontal line in the scroll bar wherever people are mentioned). Anybody who doesn't follow the workflow/procedures isn't doing their job, so there's no "I didn't see it" issue as such.

Perhaps a flashing coloured line for an unseen conversation would be advisable, or perhaps the option to send reminders about unseen conversations that are relevant. My brick Nokia phone in the 90s would carry on beeping every x amount of time if I had an unread text, it was surprisingly useful.

There are a lot of social media apps (I think Instagram is one of them) that sends a reminder push notification that you've got an unread message if you haven't seen it after x time. Something like this would be very useful to configure, perhaps even adding an option to send a reminder email if a message goes unseen for y time.

What I would like to propose for serious consideration to everybody here is the idea of a "Summary" or "What's New" view when people cold-launch the app (when it's not been running in the background) and have that as the default screen after logging in, providing an overview of things relevant to them that are unread, or tagged for "follow-up" later (similar to pin/star). With that said, this kind of overview may be useful to be accessible at any point. Perhaps calling it "Dashboard" would be logical?

With that said, Facebook's notification system that provides a timeline of relevant notification to you with colouring within the UX to indicate seen/unseen could be useful. A number next to "Unread" and being able to click "Unread" might work well; it's already in the Rocket.Chat UX, so it wouldn't take up an additional line anywhere.

I think it depends what kind of a workflow your business has as to whether threading will be relevant or work for it,

@HammyHavoc I think the relevance and usefulness changes from moment to moment. One day a channel will be quiet, or busy but with only one issue being discussed, and threading is an impediment to getting people to reading messages. The next day there'll be several issues being discussed simultaneously, and the lack of threading causes great confusion.

I think being able to swap between threaded and unthreaded views is the only way to deal with those variations, and that looking for one universal view that works well all the time can't succeed.

@pshute Completely agreed. Flexibility is a must because every user is going to have different needs, and those needs most definitely change constantly. I think most people on this Issue can relate with email with their inbox, tags, categories, search, focused view, filtering etc. They're all tools that even casual users dip into these days as the volume of information is so massive.

https://github.com/RocketChat/Rocket.Chat/pull/11803#issuecomment-445110477

A small update of possible UI using that PR as base.

@geekgonecrazy Can you, please, add this issue to January 2019 Projects board? Since it's planned to be released in 0.74 and it's already a PR ready for it. Thanks.

Just thought I'd mention that Flowdock (see threading example in the 4th post in this issue) allows "re-threading" - ie making existing messages part of an existing thread.
http://blog.flowdock.com/2017/08/31/the-1-customer-request-has-arrived-re-threading/

@7hibault have you ever used a true multilevel threading system? I think the last time I did was back when usenet was big. I think I used the Agent client, and it could show the threading as a tree. While it sounds like a good idea, when people have an unlimited number of levels, it tends to just get deeper and deeper. Some people will start the Rocket.chat equivalent of an entire Rocket.chat instance many levels deep, and happily never start a new thread ever again.

Looking at how Facebook works, with posts, replies to posts, and replies to replies, I would say that's enough levels. Any more just allows people to cause confusion. I would argue that if Facebook allowed for quoting, just two levels would be sufficient. Beyond that, people should be starting a new thread.

We already have the basic mechanisms for threading. Using the Reply command inserts the URL of the message being replied to. That alone is sufficient to allow for the messages to be displayed as a thread, with infinite levels if desired. What needs to be decided is how to display them. Currently that URL is hidden, and the URL target message is displayed as a quote instead. It could instead be used to indent the message under the URL target message, or to just colour the two messages the same, or to hide the reply message in the main message list and display it on the right like Slack, etc.

Suggestions to allow/force/ban threads in particular channels can work by just restricting the available display schemes, while still allowing for the Reply command to be used.

BTW most of our devs use free-slack and say me... speak in treads and after subject of conversation come to end - close tread. but how we can find any text on tread that already closed if we need some? it transform to read-only channels or groups?

Treads in slack imho viewng so confusedly..... search any info(text,url) becomes difficult...
if dev-team was release treads functionals in rocket.chat some people was happy to use it.
but how one of the people in this thread said - culture of use tread need to bring up

I'm not sure if I'm adding anything really useful to the conversation, but I have found the threading in Microsoft Teams to be quite useful. As many others have said, it helps group messages in one channel by conversation, but it's not intrusive and doesn't require extra work (by the user) to get right. I'm not familiar with many of the other solutions mentioned in this issue, but I find my (quite newly installed) rocket chat system a bit restricted due to the lack of threads - I see myself creating lots of additional channels for specific discussions, and of course this is bound to fail occasionally and result in confusing content.

So, my vote for threads, hopefully soon!

Please follow this bug (there is a test version you can try)

https://github.com/RocketChat/Rocket.Chat/pull/11803

A problem with this PR :
If threads are already created and a new user registers to the RocketChat server, it's impossible for him to see messages in the threads.

@Zegorax what do you mean? in the PR -- threads are just channels basically.

@robbyoconnor @Zegorax may be referring to the behaviour of the test site, where clicking on the Thread button for a thread you're not already part of doesn't do anything. Only way I found to get into them is to use the channel directory, and try to work out which one it is.

Hopefully this has been fixed in the code by now, just not running on the test site.

Yes, it's exactly that behavior

Le 21 janv. 2019 à 00:42, pshute notifications@github.com a écrit :

@robbyoconnor @Zegorax may be referring to the behaviour of the test site, where clicking on the Thread button for a thread you're not already part of doesn't do anything. Only way I fond to get into them is to use the channel directory, and try to work out which one it is.

Hopefully this has been fixed in the code by now, just not running on the test site.

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

Please discuss the PR in the PR. This issue should be implementation agnostic.
https://github.com/RocketChat/Rocket.Chat/pull/11803#issuecomment-455963816

@wreiske Any updates?
Our company (200+ people) want to move to RC but lack of this feature is a blocker for us.

I have the feature working checkout my forked branch

this is a forked branch from commit abe1f41202375641f2213afd29314e0fb6f22113

https://github.com/cooderzinc/rocket.chat.reply.threading

@khaledalyawad This is exactly the kind of threading I would expect. The existing PR for threading does not satisfy our organizational requirements. Unfortunately I'm having trouble comparing your fork to the original since there's no commit history. Do you think you could open a PR here so we can check it out?

I need help in merging

https://github.com/cooderzinc/rocket.chat.reply.threading

@khaledalyawad I have just briefly had a look at your implementation 👍 . I'd much appreciate you open a PR, since then we can discuss it better (even if un-merged!). This thread should be focusing on the issue and functional requirements.

I'd like highlight some fundamental challenges of inline threading vs. a heavy weight threading:

• How to notify users in the parent thread that new messages have occurred in the thread?
• How to order threads with newer messages inside the parent
• How to handle display on mobile (in a messenger style)

Imho, there needs to be more specification of how the system shall behave - just like I have stated in my comment of my implementation. And that's what only @RocetChat/core can provide

PR https://github.com/RocketChat/Rocket.Chat/pull/13394

So now with PR #13394 and #11803 we have two implementations of this. There are also outstanding requests in this issue for Flowdock and Zulip like features. The remaining features would be highlighting of threads in flowdock, and the topic isolation feature of Zulip, and the ability to rethread messages.

Would it be feasible for #13394, that instead of setting parentMessage._id and replyIds, when a reply is created, it sets a message topic like zulip? So when someone replies, a placeholder topic is set until a user creates one. The placeholder would be overwritten, and the topic would then become the reference instead of parentemssageid and replyid.

This would also allow for eventual subheaders/zoom in feature under channels in a later PR like zulip has, and the ability to highlight individual threads like flowdock, both based on the topic. Rethreading messages could work the same as when the first reply is created, by changing the value of the topic for that message.

@rodrigok @engelgabriel @sampaiodiego @marceloschmidt Hello guys. I am just tagging you because you are the most active contributors. Do you have any ETA when any of these PR will be merged? Can I help somehow? I think absence of this feature if one of stoppers why many companies can not use Rocket Chat. In any even medium size company if you have at least 10 people in the same channel without threads it turns into a mess and it immensely hurts productivity by distracting people with not relevant new messages and as a consequence people start ignoring notifications or disabling them completely and it hurts productivity in many other ways. I do not really understand why thing like this is not a priority.

@AlexanderBartash try http://threads-new.rocket.chat

+1 for threads. I love the way slack does it, where it just pushes open aside panel on the right for a thread, and you can open/close from there. I joined the test enviro threads-new chat but I couldn't respond to other user's threads even if I join, only to my own. Is that a setting?

thanks @maitri3 .. it was a bug.. I've fixed already, but haven't updated the test server.

closed by #13541 :)

surely you can't be serious?

why is this closed? Sure, now the answers are visibly correlating, but this implementation is still bloating the main conversation - what threads actually wanted to avoid.

Slack and Mattermost are doing it right. There's nothin but aside panel.

I have to agree that this implementation of threads does nothing to support my team's use cases.

Specific issues include:

• Inability to include the entire channel in the thread without adding members individually.
• Losing my spot in the current conversation when opening a thread.
• Difficulty in starting threads (should be as simple as "reply").
• Threads are polluted with "User has joined the channel" (first off... why is it a "channel?")
• Side-bar is polluted with a list of threads I'm in (in everyday Slack use I might be in 30 threads)

Bottom line is I would argue that the approved & merged implementation does not seem very polished or familiar for most potential users.

surely you can't be serious?

why is this closed? Sure, now the answers are visibly correlating, but this implementation is still bloating the main conversation - what threads actually wanted to avoid.

Slack and Mattermost are doing it right. There's nothin but aside panel.
dont worry.

Looks in release & it still beta.

As one of the contributors to the current implementation, I feel the need to respond here.

what’s been done

The ability to spin off a conversation has been requested long time back. This „conversation out of a conversation“ is what’s called a thread. There are several ways how to present that. Gabriel provided a nice overview how differently other chat solutions handle this.

@vickyokrm and I implemented something which works for us on our fork - and contributed it as a base for the current implementation. A lot of the implementation details have been chosen due to the existing data model of Rocket.Chat. Even for such an important feature, you cannot change the whole architecture - at least not easily.

After we raised the PR, Rocket.Chat core members have adapted the implementation as per their idea of how it should work.

Now, an initial version has been merged. Surely, there will be bugs and further functional enhancements - but I prefer starting somewhere compared to going nowhere ;-)

unhappiness with the current implementation

By making decisions, you always compromise on the alternatives. If you preferred an alternative (e. G. you don't want to have threads appear in the sidebar), you now have the ability to create a dedicated issue for that. Then, you can discuss with the community and the core team what the tradeoffs are. If you can code, you are now provided with a basis from which it is comparatively easy to create a PR which has a probability > 0.1 to be mergeable.

@khaledalayawad has done this for a tab bar based visualization with https://github.com/RocketChat/Rocket.Chat/pull/13394 and we can discuss the remaining tricky parts there. With the changes done now, he can adapt his code (which I‘d appreciate) and hopefully the whole community will benefit from it.

Community and expectations

I can’t help but writing a final statement about the general expectations and tone:
This project is a true open source project. Its community and the product benefit from each other. Please value that the maintainers give their software to the world the way they do. Comments like „you can’t be serious“ are not improving on product or community - and it couldn't be more inaccurate: we all (maintainers and contributors) are more than serious about what we do - since we invest effort and time into that.

So if you find things which don’t work (or could be improved), I’ll value the time you invest in writing and discussing it in dedicated issues.

I agree with @mrsimpson that @Shaverdoff 's [edit: should have said @port22, not @shaverdoff] initial comment is unhelpful, but I have to say I was also surprised that this issue is closed and done after providing a solution pretty much at the other end of the scale to the initial request, which was for threading "that works like Flowdock", ie the lightest type of threading. We're starting off with the heaviest type.

If those wanting that style of threading follow the suggestion that "you now have the ability to create a dedicated issue for that", it could be worded identically to the first post in this one.

I'm also disappointed that people are still saying things like this:
"Slack and Mattermost are doing it right. There's nothin but aside panel."
I think it has to be understood that there's more than one way of doing things, and what works for your team may not work for another, and that what works best for a team can change from day to day.

Thanks to everyone who worked on the current solution. I'm hoping that the data structures put in place by #13541 allow for both Slack and Flowdock style representations and encourage anyone with the time and skills to work on those.

I agree with @mrsimpson that @Shaverdoff 's initial comment is unhelpful, but I have to say I was also surprised that this issue is closed and done after providing a solution pretty much at the other end of the scale to the initial request, which was for threading "that works like Flowdock", ie the lightest type of threading. We're starting off with the heaviest type.

If those wanting that style of threading follow the suggestion that "you now have the ability to create a dedicated issue for that", it could be worded identically to the first post in this one.

I'm also disappointed that people are still saying things like this:
"Slack and Mattermost are doing it right. There's nothin but aside panel."
I think it has to be understood that there's more than one way of doing things, and what works for your team may not work for another, and that what works best for a team can change from day to day.

Thanks to everyone who worked on the current solution. I'm hoping that the data structures put in place by #13541 allow for both Slack and Flowdock style representations and encourage anyone with the time and skills to work on those.

my comment was only "looks in release& it still beta." whole of top words - is qoute of previouse commentator:) i means that developers team maybe return than some idea on best treads implementation comeback to their mind. do not see where is my " initial comment is unhelpful " let's live in pease.

i correct my previous post in order to avoid misunderstud %)

@Shaverdoff yes, sorry, I've edited my reply.

Am I understanding correctly that there is a beta release which implemented this new threads possibility? (I am just using docker.io/rocket.chat:latest).

I agree with @mrsimpson that @Shaverdoff 's [edit: should have said @port22, not @Shaverdoff] initial comment is unhelpful, but I have to say I was also surprised that this issue is closed and done

I didn't read that he complained about my comment?
Anyway, my comment was actually indeed not meant to be helpful per se, but just a complaint that this issue is closed, as obviously most users seem to not be happy with the current implementation (though it perhaps is in some beta branch).

there's more than one way of doing things

yea well you could say that. But I say, I assume the Slack team invested much time to try out which kind of implementation works best for most. And I never heard someone say the Slack implementation wouldn't be sufficient. At the other side, every slack user migrating to Rocket.Chat is complaining that threads are not possible. What Rocket.Chat calls Threads is actually just a quote feature.

I just deployed an instance with the image docker.io/rocketchat/rocket.chat:1.0.0-beta.2

As for the thread not being a sidebar, but a channel of the type "Thread" is absolutely ok for me.

It was just not obvious to me that there is a newer release which has this feature implemented :+1:

Edit: Dumb question, but how do I know when this feature is available in the :latest docker image so I can switch back to stable?

"But I say, I assume the Slack team invested much time to try out which kind of implementation works best for most. And I never heard someone say the Slack implementation wouldn't be sufficient."

@port22, my team moved to Rocket.chat from Slack soon after threads were introduced. They were too useful to not use, but were causing problems. Eg someone would reply as a thread, and then some of the team would participate in the thread, others wouldn't even realise it was there, and would continue the discussion as normal replies. I would tick the box to post a copy of a thread reply to the channel to help alert them to the thread, but that creates clutter.

We'll have to try this implementation to see how it works out, but I'm not hopeful. I would really like to try the Flowdock style as a compromise. Even better to be able to swap between styles.

Edit: Dumb question, but how do I know when this feature is available in the :latest docker image so I can switch back to stable?

Short answer - when it is released.

Watch the releases/tags https://github.com/RocketChat/Rocket.Chat/tags - you can write yourself a little script to check for updates. It's very simple to do.

Note there may be several Beta and RC releases and it may take weeks, or even months.

So you should really have deployed a test version first.

I actually wrote a script which is checking releases (https://github.com/RocketChat/Rocket.Chat/releases/latest), but since all 1.0.0-beta.2 are not marked as "pre-release", then I am getting notifications about upgrade every day even its not updated, because :latest docker is 0.74.3 :)

maybe cc: @sampaiodiego

Note that EVERYTHING is essentially pre-release so far. v1.0.0 will be the first full release. Everything before it was Alpha/Beta.

You just need to modify your script - mine works fine - went from 0.74.3 to 1.0.0-beta.0/1/2 etc without missing a beat.

eg

===========================
Subject: RocketChat Server New Version 1.0.0-beta.2 available
From: [email protected]

New Rocketchat 1.0.0-beta.2 available
https://github.com/RocketChat/Rocket.Chat/tags

===========================

RocketChat Server Update - No New Version Available
From: [email protected]

Current version 1.0.0-beta.2 - no updates available

===========================

Then :latest docker image should be also 1.0.0-beta.2 :)

No, it should not. The latest image is never pre-release versions.
On 3/19/19 4:00 PM, Jindřiška wrote:
>

Then :latest docker image should be also 1.0.0-beta.2 :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RocketChat/Rocket.Chat/issues/1112#issuecomment-474555054,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABaMFFa0RCaZ-J5RBB3iZCQrtKUZlTCks5vYUHqgaJpZM4GPgO-.

Then beta releases should be marked as pre-release :D

Then beta releases should be marked as pre-release :D

They are.

The fact of the matter is this: ALWAYS check the latest release -- if you are running this in production and not checking the latest release and what changes happened, you are being extremely irresponsible as a sysadmin. It says beta in the name.

in fact beta releases were not set as pre-release.. sry about that.. I have fixed them all.. thanks for the heads up

I'll also hide all conversation about this as offtopic.

I just wanted to add that the threading support in #13541 does not work with the internal SlackBridge. Threads in Slack are still transported without any indication that there is a thread and threads in rocketchat are not transported at all

We have decided that was better to delay our v1 release and get the Threads done properly than get the feature out the way it was initially implemented on the develop branch. We have "rebranded" our current implementation of Threads to Discussions (was it creates a new room type) and will implement Threads exactly the same way as Slack does.

In our vision there are 2 different use cases on how to break out of the main conversation: one very easy and organic, with a single click for small side talk, and other, much more structured, that creates a new conversation with its own life cycle.

We have tried to have a single solution for both, and as a result, no one was happy with it.
So we have given up on having a single approach for both use cases and will implement both: the Slack-like industry standard and our brand new one, called Discussions.

https://github.com/RocketChat/Rocket.Chat/issues/13843

@engelgabriel can you please clarify how threads and discussions will differ? Are they just different representations of the same underlying data?

Are they just different representations of the same underlying data?

No, totally different data models.

• Discussions = new channels that inherit permission from the parent channel
• Threads = same channel will be like the reply action we have now, but add the parent message property to the messages, so they can be displayed on the sidebar.

Hey all, appreciate the delay to improve the implementation. Is it planned to have these features toggleable? e.g. turn on _only_ threads but not discussions?

It's a great power user feature to have both, but I can see this confusing the hell out of our users, especially if the mobile applications would take a few months or so to catch up.

Both these features will be toggleable.

No, totally different data models.

@engelgabriel thanks. Can I please request that a Flowdock style display be considered for Threads in addition to Slack style? I think it should be easier to do than Slack style because they're displayed with the other messages in chronological order, just coloured to identify each thread's messages.

[Edit: should be able to toggle between Slack style and Flowdock style.]

Guys I raised another PR of slack like threading https://github.com/RocketChat/Rocket.Chat/pull/13805

Hello!
Do you have API to post a message as "reply in thread" or "Quote"?

you can use chat.sendMessage and set the tmid property as the message you want to reply in a thread.

I miss the Flowdock ability to take a message that I posted and after the fact rethread it back onto a existing thread.. Any way to do that in Rocket.Chat?

I miss the Flowdock ability to take a message that I posted and after the fact rethread it back onto a existing thread.. Any way to do that in Rocket.Chat?

I'm interested in this too. Being able to thread is only part of the problem. There will always be misthreaded messages to deal with.