element-x-android
element-x-android copied to clipboard
element-hq
Threads support
Your use case
Hi, I'm missing the threads in ElementX.
When some people in a room use threads, reading the messages in elementX becomes a mess.
It's also a vert useful feature even on simple friends messaging groups.
Will it be implemented soon ?
Regards
Have you considered any alternatives?
No response
Additional context
No response
Are you willing to provide a PR?
No
An interim solution would be to provide the option to create a thread via the context menu of a message.
Currently, the context menu of messages inside a thread is as follows:
The context menu of regular messages looks like this:
One could add the option "Reply in thread" here, too.
This is still an issue why we don't move the entire team to Element X from a legacy client
Threads are must have in 2k24
Could maybe someone from the dev team give some info about when we can expect full threads support? I was not able to find any roadmap or any other kind of information about it. For me this (and spaces) is the top missing feature in element-X. It would be also nice to know the motivation behind prioritising other features like image captions, gallery and similar. I do not mean to sound ungrateful, I realy appreciate the work you are doing on element, It would by just nice to know what and why is going on. Maybe you could even publish some broader roadmap for 2025 as a christmas gift for all fans of Element and Matrix(?)
Element X development still depends on features funding. The features you listed have been sponsorised. They are quite useful to make EX closer to mainstream messaging apps for non techy users. We basically follow what Element's customers need and pay so that we can continue to work on the project.
We also consider threads and spaces to be super important too. We already worked a lot on them on the product and UX sides with design prototypes, user and customer interviews., etc. This work is not visible here on GH but it takes a huge amount of time. I can confidently say those features will be more useful (even usable) for end users when we will land them in the EX apps. Next step for us is to align stars (and sponsorship) to priorisite the implementation. Hopefully, it will happen soon.
As you may know, funding a FOSS project can be a rollercoaster. We stopped publishing our roadmap long time ago because people did not want to sponsor a feature Element is going to build for free for them.
Why not show in the roadmap unsponsored features (in place of backlog), along with the priority of the sponsored ones.
Have you considered implementing some band-aid approaches in the meantime? When you reply to a message in a thread in gomuks, you have the option to have it "add to thread" or "reply to message in thread". Maybe you don't want temporary/half solutions, but if it's going to be months or years before threads exist, maybe something easier to implement would make sense in the meantime, at least as a labs feature?
+1, the lack of threads and Spaces is a hard blocker for many people to migrate. If Element wants people to move to Element X, these are requirements
I really wish Element wouldn’t try to push Element X until it’s ready. Right now we have two incompatible clients, especially when it comes to phone calls.
I’m going to be blunt: the current stance on prioritizing Threads is completely off-track. Element X’s product management approach here is, frankly, 100% wrong. When you’re trying to attract serious enterprise users, especially the thousands of organizations currently relying on Slack, Threads are not an optional “nice-to-have.” They are the core functionality many businesses require before even considering a migration.
Here’s the evidence:
-
Established Precedent in Enterprise Tools Slack, Microsoft Teams, Google Chat, all of these platforms have robust threaded conversations. This isn’t a secondary feature; it’s central to how large teams reduce noise and maintain clarity. If Element X doesn’t match or improve upon this standard, it won’t even appear on the radar of companies looking to switch.
-
Essential for Large-Scale Collaboration Threads let teams break off side-discussions without cluttering the main conversation. When you have hundreds or thousands of employees in a room, unthreaded chats become chaotic and unmanageable. Decision-making slows to a crawl as people scramble to keep track of who said what and when. Threads drastically improve signal-to-noise ratio. They keep tangential discussions, clarifications, and question/answer pairs neatly organized, so the main channel can stay focused on the central topic.
-
Critical for Onboarding and Retaining Users Migrating from Slack to Element X is not just about replicating chat logs; it’s about preserving familiar workflows so teams don’t skip a beat. Many Slack power-users rely on threads every day for project management, quick feedback loops, and knowledge-sharing. Without fully functional threading, any attempt to move over from Slack fails instantly because user friction shoots up. Confusion, frustration, and churn will follow, people simply won’t adopt a solution missing the single largest advantage of Slack-like platforms.
-
Evidence from User Feedback The conversation around “Threads support” is consistently the most common (and often heated) request from potential enterprise adopters. Dozens of open-source communities, software developers, and corporate teams have all said: “We want to move to Matrix/Element, but we can’t without Threads.” Every time the topic comes up, you see the same points repeated: there are “two incompatible clients,” confusion around half-baked or incomplete features, and a total roadblock for any serious Slack replacement strategy.
-
Long-Term Viability and Growth If the plan is to position Element X as a true Slack or Teams competitor, ignoring the importance of Threads will only repel exactly the customers who might be paying for these enterprise features. Threads are not just a “techy user” feature. They are a basic organizational tool that influences how entire departments communicate. Any sales pitch or demonstration of Element X to large companies or governments will fall flat without it.
Element X can’t fully claim feature parity with other mainstream chat tools if Threads remain an afterthought. The entire premise of a Slack alternative hinges on the ability to handle focused, parallel discussions at scale, and that’s exactly what threads enable.
In short, Thread support must be top priority. It is the gatekeeper for large-scale adoption, far more critical than nice-to-have additions like image captions or gallery views. Without robust threading, thousands of interested organizations (my team included) simply cannot move from Slack to Element X. If the goal is to grow and thrive in this space, Threads aren’t optional; they’re fundamental.
Element X development still depends on features funding. The features you listed have been sponsorised. They are quite useful to make EX closer to mainstream messaging apps for non techy users. We basically follow what Element's customers need and pay so that we can continue to work on the project.
We also consider threads and spaces to be super important too. We already worked a lot on them on the product and UX sides with design prototypes, user and customer interviews., etc. This work is not visible here on GH but it takes a huge amount of time. I can confidently say those features will be more useful (even usable) for end users when we will land them in the EX apps. Next step for us is to align stars (and sponsorship) to priorisite the implementation. Hopefully, it will happen soon.
As you may know, funding a FOSS project can be a rollercoaster. We stopped publishing our roadmap long time ago because people did not want to sponsor a feature Element is going to build for free for them.
@leonardehrenfried we need a paradigm shift here. The conversation isn’t actually about money or funding. That mindset misses the fundamental point: success hinges on delivering the features and experience people need, not on how much budget you can throw at the problem. Slack and Teams didn’t blow up just because they had big funding, they solved a real workflow issue by making threads the heart of team collaboration. If Element X wants that same level of impact, it has to prioritize what users truly care about. Budgets and funding follow when the product delivers genuine value. Shift the focus from finances to the actual user experience, and the rest will fall into place.
If all Element X cares about is getting money to get features funded and nothing else, that's fine. But then please, stop trying to push it as a replacement for Element, because it clearly isn't. And not only is it not, you clearly don't want it to be a replacement, as it's not even planning to be feature complete to not risk funding. At this point, the damage to the ecosystem is immense. Please stop pushing Element X and instead tell people to go back to Element.
Element X is currently only usable for conversations with friends and small groups, like Whatsapp. It's getting pushed for this usage. Element is totally usable for work-related usages.
As mentioned here, does this ticket actually belong against element-meta instead? Also, is there a ticket for spaces support somewhere?
Just out of curiosity, how much money would threads require? Ball park @manuroe
Several X in $X00k. We learnt that threads as they are specified in the matrix protocol are not enough for a good UX. We want to add a participation model at the top of them. With threads 2.0, users will be automatically notified for new messages in threads they participated in. There will be a mechanism to register and unregister notifications for a threads. If I can make a comparison with GH, it is going to be very similar as how you have notifications for GH issues.
Threads 2.0 is to be defined. We need a new MSC for this new Client-Server API and implementation in Synapse, EX and EW.
Ok… that's big ahah
But then a question remains: I suppose these threads 2.0 are going to be backwards-INcompatible with the current threads? Is this something that the Matrix community really wants to do? Has this been discussed publicly? Or only internally?
Do not be scared. 2.0 is more a marketing version. There will be no incompatibility issue in the Matrix ecosystem. Threads 1.0 is what the protocol currently defines. Threads 2.0 will use Threads 1.0 and will add this participation model in a new separated API.
Threads 2.0 clients will be able to communicate with Threads 1.0 clients and vice versa. The difference will be on notifications: Threads 2.0 clients users will get notifications for messages in a thread while it will stay "complicated" for Threads 1.0 clients users
Several X in $X00k. We learnt that threads as they are specified in the matrix protocol are not enough for a good UX. We want to add a participation model at the top of them. With threads 2.0, users will be automatically notified for new messages in threads they participated in. There will be a mechanism to register and unregister notifications for a threads. If I can make a comparison with GH, it is going to be very similar as how you have notifications for GH issues.
Threads 2.0 is to be defined. We need a new MSC for this new Client-Server API and implementation in Synapse, EX and EW.
Please consider to add also a way to tag the threads as "closed/completed" or "open" and a way to hide/archive threads. These solutions would be very useful to periodically clear the clutter and maintain a clear vision of stuff going on. Thank you!
Has Threads 2.0 been planned with consideration towards Zulip-style or Twist-style topic-based (threaded-only mode) on a per-room basis (or per-server)?
From @KB1RD's comment on the completed element-web ticket, it sounded like https://github.com/matrix-org/matrix-spec-proposals/pull/2326 was work towards that use case, but maybe that has been abandoned since the v1 threading implementation landed.
Thank you for keeping this on the roadmap – I really appreciate the transparent communication and steady development! Thread support is such an important feature, especially for active rooms where things can get messy without proper structure. I’m genuinely looking forward to seeing this in Element X – thanks for all your hard work on it!
Just tried threads on Element X after activating the experimental option, it works !
Great, no need to use Element classic anymore.
OMG, thank you for this message! I have been waiting for this for a long time.
It works great - thanks to everyone involved!