Threaded Messaging #2349
Comments
|
The plan is to do REALLY good threading in Riot. There's a lot of work on this currently on the Matrix spec, backend, and we're starting work on the frontend next week. matrix-org/matrix-spec#411 is the design bug for this (although there's nothing there yet). I'll keep this one around too. Thanks for the overview of what other folks are up to here! |
|
Looks like Slack have implemented this now as well. Cool UI: And an overview page: |
|
flowdock also implements threaded conversations in a nice and very usable way |
|
Twist from creators of Todoist uses the very interesting concept of threaded channels: In these channels every message must be in a thread, and it makes conversations much more organised than a continuous stream of messages. It's the modern version of forum, except you get the benefits of organisation and don't miss out on integrations, mentions, presence, bots etc. |
|
this is not p1. |
|
I believe this should be a p1 issue, almost all other chat platforms have some sort of implementation of threaded messages. Would be happy to assist in the development of this! |
|
I see this as more of a nice-to-have. Slack didn't even have it for a while. I'd say element-hq/element-meta#347 is more important as there's currently no way to reset the message pointer, which most other systems have had for a while. |
|
I definitely see this as a p1, not a nice to have. Constant noise is a major complaint for utilizing chat platforms in business settings, and threading cuts down on that noise by grouping conversations and allowing a user to essentially ignore it. This was a major improvement in Slack, and most people who have used threaded messaging do not want to go backwards. |
|
I'm evaluating Riot.im for use at my work and with a couple of NPOs that I'm involved with, but sadly the answer is a firm NO until 1st class threading (like Flowdock, unlike Slack) is implemented. 1st class threading means each message can be it's own thread, and each reply has all chat features available. Slack screwed this up, you can't add attachments to thread replies etc. |
|
Hi, I just want to say that I am also evaulating Riot for an organization... this feature is critical in making the move to this cool software. I'll certainly be watching for updates. Cheers |
|
Also, adding my experience, that when trying to convince groups to use Riot instead of Slack, threading was sited as the reason to stay with slack. And I can't disagree, noisy topics can be a real pain. But I'd really like to move to an open source option with end to end encryption like Riot |
|
#metoo |
|
For our organization is also a very important feature. Without it is almost unusable for us. |
|
I've heard a lot of good about threading in Zulip, but it might be hard to implement in Matrix due to the focus on rooms instead of topics |
|
Yes, Zulip is interesting solution for threads in chat, but the problem that topic is obligatory field - this is not hard to implement, but this will got problems for people with free chatting (offtopic chats). Maybe good solution will be do this feature at per-room basis, to require all messages with topic only on specific rooms. |
|
I'm surprised that no one has pointed to Microsoft Team's implementation of threaded conversations. It's nothing to write home about, but it's good to have to keep different conversations separate. Just wanted to point out another competitor that has that implemented. |
|
So far mattermost has this down Has there been any movement on this? |
|
someone is working on replies, is it @t3chguy ? |
Or rather like in Reddit or Medium. |
|
Hey people. Does anyone know, when this feature is going out of beta and also into the mobile app? It’s the only thing that’s holding us back from using it. |
I don't know when it's coming out of beta, but you can already enable it in the mobile app (I'm using v1.4.2 from F-Droid) by going to Settings > Labs > Enable Thread Messages |
Thanks for the fast replay! (: |
I don't have an IOS device, but it looks like it should be available as of 1.8.0 on IOS: The app store lists 1.8.3 as the current version: So I imagine you can enable it in the same place |
|
It's possible to enable in Android as well in the labs settings, and it seems to work great in the little I've used it. Though from a user perspective it's not much use until it's on by default for everyone. Otherwise, the only people who use it are people who know about it and go looking for it. |
|
I've read through most of this thread. It seems like Matrix/Vector is (so far) going for the "Slack-style threads", and not the "Twist style threads", is that a correct understanding? (cannot find any screenshots or design doc) As others have pointed out, it would be great if we could (optionally) make rooms threads-only:
For now I guess we'll be staying with Twist. |
|
Threads-only rooms would basically be spaces with threads-as-rooms, only with a magnitude more associated MSCs. Just an observation |
|
Yes. I wrote a proposal for that, which magically disappeared. A short summary is here. |
|
I believe they've fully committed to the idea of adding threads to the spec and basing it on replies. I do not agree but the door seems rather closed on further discussions about this. The arguments against threads-as-rooms boiled down to
Now (1) sounds like a more general problem to me and (2) hasn't stopped reactions or spaces from being implemented. But I digress - moaning about it isn't likely to change their decisions. |
They aren't based on replies, they're based on relations, they fallback to replies so any client with handling for replies will see threads as replies until they add threads support. (Reactions, Edits & Replies are all based on relations) |
But that removes point (1) in that case, because it's not backwards compatible any more than threads-as-rooms. With throoms you could also show replies in the thread-room as replies in the original room. Edit: or actually, more properly simply show them in the original room, not as replies but as normal messages, perhaps with a little notice that it's from a thread and with a link to the relevant room. That way, a client not implementing throoms would lose nothing while one that does sees more organised conversations. |
|
It doesn't touch the performance of rooms in the slightest, so does not remove point
Duplicating all messages between the thread room (throom) and the parent room is horrific and will create a potential for edits/redactions to get desynced between them. |
Sorry - obviously I meant to refer to point (2).
I was thinking of a more sophisticated fallback than copying the events, using shared events between rooms or aggregate timelines. |
|
Given that the backwards-compatibility of threads-as-replies rely on MSCs for relations (correct me if I'm wrong), I think it's fair to compare it to backwards-compatibility of throoms + an MSC for shared events between rooms or aggregate timelines. The events in the original room could be references to events in the thread room, creating no duplication and perfectly integrating with the throoms model where you probably want the ability to see events from sub-throoms in the main room. |
|
Under the advanced settings of a space I've opened the developer tools, then the settings explorer. I've changed the default value of feature_thread from "false" to "true". I've pressed the button Save setting values and the Windows app restarted. But I haven't reached the goal of enabling threaded messaging. (When I open again feature_thread, the code is unchanged.) Where have you published instructions on how to do this? Not here. |
|
Use develop.element.io then go Settings > Labs > Threaded messaging |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
That is off-topic for this issue. |
|
Threads are now in Beta as of 1.10.9 |
|
@t3chguy Could you, or anyone please also link the latest spec used as a base of the implementation? There are way too much comments to find it easily. Thanks! |
The biggest problem I have with threads (and raised independently by at least one colleague), is that it becomes very difficult to follow the conversation on a thread if someone comments on the thread a day or two later - their response gets lost and doesn't have the same immediacy as when something is on the 'timeline'. If the message appears in the usual 'timeline' like a quoting reply, as well as being able to browse the thread, then that will be great! If it doesn't, then it will be as painful as Slack etc. Sadly, the way I understand the intended implementation from the front-end side (element-hq/element-meta#3), the intention is for anything on a thread to NOT show in the 'timeline', by design. 😢 |
|
Please open new issues for further discussion about threads :) Locking this as resolved in the meantime. |
and others
Extending the Quote functionality to allow for threaded messaging.
This could be a simple 'Quote 2.0'-style like WhatsApp where the quoted text is hyperlinked and when clicked makes you scroll up to their message:
Or the more sophisticated Threaded Messages panel like Mattermost:
Perhaps allowing for both could be done by having the Threaded Messages panel open when you left-click on the 'reply' part of the Quote 2.0 message:
Or by having 'Message Thread' popup as an option in the context menu to allow opening the Threaded Messages panel:
The text was updated successfully, but these errors were encountered: