Giving Up on Element and Matrix.org(xn--gckvb8fzb.com)
xn--gckvb8fzb.com
Giving Up on Element and Matrix.org
https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg/
149 comments
For the past decade or so, I have used Conversations on mobile and Gajim on desktop. Seems to work fine with a minimum of work. What am I missing?
Gajim has been genuinely pretty unstable and buggy for me on Wayland (Sway) with lots of "crashing", in quotes because they tell me it's not crashing if I try to report it, but it's more like the windows are lost suddenly (this has improved over time somewhat at least, it used to be the whole client several times per day and now it's just the file picker, which can mostly be avoided). As for Conversations, mostly works great, if I had to complain it would be that you're forced to use relative timestamps with no way to configure them.
To compare Matrix and XMPP, I like that with Matrix you can edit messages that are as far back as you want, not just the most recent one sent from the same device you're on. Sometimes I fire off a storm of messages and then while I'm waiting for replies I go to read over them again and catch some things I wanna fix that I didn't see before. I also like that Matrix is a bit more distributed in that if the homeserver the room is on/from goes down, everyone else can still chat. I even have a group chat originally made on a now completely dead homeserver but we're all still happily chatting in it. I'm using both XMPP and Matrix daily, but Matrix is the one I got IRL friends and family on. XMPP seems more popular with people from fedi and the like, what you might call "internet weirdos". I have considered trying to convince more IRL contacts to get on XMPP, but I'm not sure they could handle another move, and I'm not sure I could justify it when it's not an objectively better across the board upgrade. When we moved people off Facebook chat or Google Hangouts, we were going from something proprietary and centralized to something free and decentralized, also there was encryption I guess. XMPP is kind of a sidegrade. Ideally it wouldn't be a full move anyway so much as getting them all to sign up on it as back-up comms, but again I'm just not sure they could be bothered at this point.
To compare Matrix and XMPP, I like that with Matrix you can edit messages that are as far back as you want, not just the most recent one sent from the same device you're on. Sometimes I fire off a storm of messages and then while I'm waiting for replies I go to read over them again and catch some things I wanna fix that I didn't see before. I also like that Matrix is a bit more distributed in that if the homeserver the room is on/from goes down, everyone else can still chat. I even have a group chat originally made on a now completely dead homeserver but we're all still happily chatting in it. I'm using both XMPP and Matrix daily, but Matrix is the one I got IRL friends and family on. XMPP seems more popular with people from fedi and the like, what you might call "internet weirdos". I have considered trying to convince more IRL contacts to get on XMPP, but I'm not sure they could handle another move, and I'm not sure I could justify it when it's not an objectively better across the board upgrade. When we moved people off Facebook chat or Google Hangouts, we were going from something proprietary and centralized to something free and decentralized, also there was encryption I guess. XMPP is kind of a sidegrade. Ideally it wouldn't be a full move anyway so much as getting them all to sign up on it as back-up comms, but again I'm just not sure they could be bothered at this point.
As someone in the exact same boat as you (a happy XMPP user for 10+ years, with family and friends there), if I had to name one, it would be group calls and overall calls being supported in Gajim. We just hyperlink to jitsi meet whenever the need arises, not a big deal at all.
Have you tried Delta Chat? I like the concept, but I can't convince anyone to sign up to test it out :(
The best chat system for geeks is zulip. Messages threaded, everything markdown. very efficient use of screen estate.
For less geeky use I indeed have had Delta on my list for years. Haven't really tried yet myself, not to speak about convincing.
For less geeky use I indeed have had Delta on my list for years. Haven't really tried yet myself, not to speak about convincing.
People keep hammering zulip as the example of threads done right. I disagree. They are practically indistinguishable from rooms, in looks and behaviour. It's not like zulip is offering a better abstraction/isolation level: you end-up with just as many threads, as much (in)convenience dealing with them, and the exact same caveats (there's no known solution to people writing out of thread, so the cognitive load is still worse - IMO/E - than "no threading at all").
That's why I wrote it is for geeks. Maybe I should have said it's for geeks that keep don't mind the offort of their stuff/data/code organized. You need to put some thinking to use reusable topics. And when discussion goes off-topic you need know where to move it. Zulip has support to do that, other systems just don't.
I was in a company for over 6 years where zulip threads were very organized. "zulip police" would tell those starting to create a mess. It's a cultural thing. We also spent significant time to keep our code clean. 90% of the work-places keep neither their communications nor their code organzied.
I was in a company for over 6 years where zulip threads were very organized. "zulip police" would tell those starting to create a mess. It's a cultural thing. We also spent significant time to keep our code clean. 90% of the work-places keep neither their communications nor their code organzied.
> The general response from the team was: "Pay money or shut up and accept what we give you".
I think you may be unfairly paraphrasing "we don't have enough funding to be able to work on both Element & Element X, or Synapse & Dendrite, or to have landed Threads/Spaces in Element X yet, or <insert complaint here>".
> The number of gigantic changes in direction this project has had in the past couple of years is enough to sink any project. Jitsi to Webrtc, complete change in auth system, Element to Element X.
It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
* Jitsi is unencrypted by default, and doesn't synchronise identity, access control, or cryptographic identity with Matrix, and uses XMPP (Prosody) for signalling. Moving to MatrixRTC (i.e. WebRTC signalled over Matrix) gives proper end-to-end-encryption with verified identity and access control managed by Matrix. Surely this is a good thing?
* "Complete change in the auth system" is a massive improvement, in that one of the main drivers for doing it was to now be able to use any OIDC identity provider to add 2FA/MFA/Passkeys or whatever fancy auth you like (despite the OP's assertion otherwise).
* "Element to Element X. There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
> but my experience with these guys is that they're incredibly arrogant.
For what it's worth, I think i've made some spectacular mistakes in running Matrix, as well as bunch of good stuff). This came up in the TWIM offtopic room a few weeks ago at https://matrix.to/#/!xALORqBdeiSfgdrmUb:bpulse.org/$4bGbRTxN.... I've reproduced it (lightly updated) at https://gist.github.com/ara4n/8422ae8eae68a8993a5e831691b441... for ease of reference. I'll let you decide whether that sounds like arrogance or a BDFL who's too smart for his own good.
> P.S I suspect the organization is being led by Architecture Astronauts
On the Element side: does https://youtu.be/IwZ4rE_Pt64 feel like an org led by architecture astronauts?
I think you may be unfairly paraphrasing "we don't have enough funding to be able to work on both Element & Element X, or Synapse & Dendrite, or to have landed Threads/Spaces in Element X yet, or <insert complaint here>".
> The number of gigantic changes in direction this project has had in the past couple of years is enough to sink any project. Jitsi to Webrtc, complete change in auth system, Element to Element X.
It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
* Jitsi is unencrypted by default, and doesn't synchronise identity, access control, or cryptographic identity with Matrix, and uses XMPP (Prosody) for signalling. Moving to MatrixRTC (i.e. WebRTC signalled over Matrix) gives proper end-to-end-encryption with verified identity and access control managed by Matrix. Surely this is a good thing?
* "Complete change in the auth system" is a massive improvement, in that one of the main drivers for doing it was to now be able to use any OIDC identity provider to add 2FA/MFA/Passkeys or whatever fancy auth you like (despite the OP's assertion otherwise).
* "Element to Element X. There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
> but my experience with these guys is that they're incredibly arrogant.
For what it's worth, I think i've made some spectacular mistakes in running Matrix, as well as bunch of good stuff). This came up in the TWIM offtopic room a few weeks ago at https://matrix.to/#/!xALORqBdeiSfgdrmUb:bpulse.org/$4bGbRTxN.... I've reproduced it (lightly updated) at https://gist.github.com/ara4n/8422ae8eae68a8993a5e831691b441... for ease of reference. I'll let you decide whether that sounds like arrogance or a BDFL who's too smart for his own good.
> P.S I suspect the organization is being led by Architecture Astronauts
On the Element side: does https://youtu.be/IwZ4rE_Pt64 feel like an org led by architecture astronauts?
> I think you may be unfairly paraphrasing "we don't have enough funding to be able to work on both Element & Element X, or Synapse & Dendrite, or to have landed Threads/Spaces in Element X yet, or <insert complaint here>".
I asked in the chat what's the plan for people who are running on old servers when it comes to migrating to MAS. The general response was "Welp, should've gotten a support contract." Or maybe it was migrating from Element to Element X. I can't remember.
> It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
The real irony is mentioning working on both Element and Element X, Synapse and Dendrite, and not see how much work that's already been done is being completely thrown away. This is not even including all the weird 3D stuff that was once a thing. Even the all the rebranding is kind of like 'wtf is happening over there'
> Jitsi is unencrypted by default.
Then why implement it? Or you could have contributed to it/fixed it instead of building something from scratch using technologies like SFU which no has has heard of before.
> There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
Since when have threads and spaces been in development? Probably almost a year now. And this is not even including the bug/unimplemented feature where in the android app where clicking a message notification just takes you to the bottom of the room instead of the message itself. And what about clicking to join rooms? Matrix.to? Come on, bro.
> For what it's worth, I think i've made some spectacular mistakes in running Matrix,
I wasn't talking just about you, your arrogance is kind of endearing in the right light. The community itself is so hostile to any criticism it feels like talking to toddlers.
> as well as bunch of good stuff
Matrix is great. Just not ready. The communication about how it's so great and ready is probably a big reason of why people are turned off. If Matrix was still labeled beta (and people weren't afraid of New Vector one day moving development behind closed doors) I can almost guarantee the community would be so much more vibrant. The threat of New Vector going fully proprietary is the main reason we decided not to move forward with contributing to the ecosystem. (we're still looking for our messaging home).
> On the Element side: does https://youtu.be/IwZ4rE_Pt64 feel like an org led by architecture astronauts?
I remember when this video first came out. I think it was around the time of MatrixConf. Element X is not ready, and starting the video by calling it "Not just the best Matrix messaging app, but the best messaging app available" is (with all due respect) delusional, or marketing-led dishonesty.
I say all the above with love. I'm someone who has developed an admin panel for our internal proof-of-concept other than the one provided by New Vector or the other half-baked open-source one (I forget what it's called). So I've really dived deep into the ecosystem. But it's not there, yet.
I can see the vision you have for Matrix. The global federated network of eventually-consistent event servers. I love it and I hope it succeeds. But when commercial interests play a role and New Vector has some sort of conflict of interest between spreading Matrix as far as possible, and making it profitable, it's hard to buy in to that utopian vision. Be Linux, not Red Hat. You can't be both, that's where the conflict of interest comes in. Yeah Matrix is an independent foundation etc. etc. but if Synapse dies, the entire ecosystem dies.
I asked in the chat what's the plan for people who are running on old servers when it comes to migrating to MAS. The general response was "Welp, should've gotten a support contract." Or maybe it was migrating from Element to Element X. I can't remember.
> It feels ironic that our attempts to improve the project are characterised as "gigantic changes in direction which are enough to sink any project".
The real irony is mentioning working on both Element and Element X, Synapse and Dendrite, and not see how much work that's already been done is being completely thrown away. This is not even including all the weird 3D stuff that was once a thing. Even the all the rebranding is kind of like 'wtf is happening over there'
> Jitsi is unencrypted by default.
Then why implement it? Or you could have contributed to it/fixed it instead of building something from scratch using technologies like SFU which no has has heard of before.
> There's two clients. One that's fast, and one that's full featured". Well, that's true, but most people seem to feel Element X's improvements outweigh the fact it doesn't have threads/spaces yet (although they are both in dev currently).
Since when have threads and spaces been in development? Probably almost a year now. And this is not even including the bug/unimplemented feature where in the android app where clicking a message notification just takes you to the bottom of the room instead of the message itself. And what about clicking to join rooms? Matrix.to? Come on, bro.
> For what it's worth, I think i've made some spectacular mistakes in running Matrix,
I wasn't talking just about you, your arrogance is kind of endearing in the right light. The community itself is so hostile to any criticism it feels like talking to toddlers.
> as well as bunch of good stuff
Matrix is great. Just not ready. The communication about how it's so great and ready is probably a big reason of why people are turned off. If Matrix was still labeled beta (and people weren't afraid of New Vector one day moving development behind closed doors) I can almost guarantee the community would be so much more vibrant. The threat of New Vector going fully proprietary is the main reason we decided not to move forward with contributing to the ecosystem. (we're still looking for our messaging home).
> On the Element side: does https://youtu.be/IwZ4rE_Pt64 feel like an org led by architecture astronauts?
I remember when this video first came out. I think it was around the time of MatrixConf. Element X is not ready, and starting the video by calling it "Not just the best Matrix messaging app, but the best messaging app available" is (with all due respect) delusional, or marketing-led dishonesty.
I say all the above with love. I'm someone who has developed an admin panel for our internal proof-of-concept other than the one provided by New Vector or the other half-baked open-source one (I forget what it's called). So I've really dived deep into the ecosystem. But it's not there, yet.
I can see the vision you have for Matrix. The global federated network of eventually-consistent event servers. I love it and I hope it succeeds. But when commercial interests play a role and New Vector has some sort of conflict of interest between spreading Matrix as far as possible, and making it profitable, it's hard to buy in to that utopian vision. Be Linux, not Red Hat. You can't be both, that's where the conflict of interest comes in. Yeah Matrix is an independent foundation etc. etc. but if Synapse dies, the entire ecosystem dies.
> It's tough finding an open-standards based IM application for corporate use.
I didn't try it, but this seems interesting: https://github.com/jesse-greathouse/eIRC
"eIRC is a modern, scalable enterprise messaging architecture built on the IRC protocol. Designed for organizations that require ephemeral, real-time communication without the heavy operational overhead of pub/sub systems like Apache Kafka, eIRC delivers high-throughput, low-latency chat experiences while minimizing memory and CPU usage per user."
It does support history as well: "IRC History Bridge: Implement Redis-backed buffer for message replay".
I didn't try it, but this seems interesting: https://github.com/jesse-greathouse/eIRC
"eIRC is a modern, scalable enterprise messaging architecture built on the IRC protocol. Designed for organizations that require ephemeral, real-time communication without the heavy operational overhead of pub/sub systems like Apache Kafka, eIRC delivers high-throughput, low-latency chat experiences while minimizing memory and CPU usage per user."
It does support history as well: "IRC History Bridge: Implement Redis-backed buffer for message replay".
That's too far in the other direction, IMO. The IRC protocol was a poorly designed mess. Tying yourself to it means inheriting all of its bizarre quirks and limitations, and there's very little that existing IRC servers do that would be difficult to replicate.
(For a taste of just how weird and terrible IRC can be, try to answer the question "what is the maximum length of an IRC message". If your answer is a specific number, it is incorrect.)
(For a taste of just how weird and terrible IRC can be, try to answer the question "what is the maximum length of an IRC message". If your answer is a specific number, it is incorrect.)
In my understanding, IRC was not designed at all. It has more like been built in an ad-hoc manner. IRCv3 is an attempt to create a clear specificatiot.
Architecture Astronauts, and Cowboy Coding are all problematic.
This is more of a question of enough clarity, direction and alignment.
Either both groups have it, or they don't.
This is more of a question of enough clarity, direction and alignment.
Either both groups have it, or they don't.
Tech people don't like to hear this, but you also need product people. And I don't necessarily mean those with a business background, but those who can see the larger picture from the user/customer perspective and who can ensure that all of the technology is packaged into one coherent and actually useful thing.
If the project is run by those who are all deep in the weeds of low level technological details, odds are that the larger product turns into a giant mess that is all over the place.
If the project is run by those who are all deep in the weeds of low level technological details, odds are that the larger product turns into a giant mess that is all over the place.
I'm a tech creator who's a product person for a long time, as well as on the business side. Hyper-problem and user focused. Having put in the time for all 3, I agree with you fully on needing product, tech, and user experience awareness.
I can say that tech creators tend to be able to learn product and business easier than the other way around.
One reality is too many product folks don't always know what tech is capable and possible of, which can undermine the asks and the solves. So innovation can become best practices (existing) and increments from there, instead of seeing new ways digital can be delivered.
I'm all for making fun of premature optimization and abstraction into wavy concepts. That can happen as much in product practice as it does development. Maybe the sticky consumption ratio could be part of a KPI.
When building technology solutions to solve people's problems, clever architecture will always beat clever coding and clever product people. Because you make both product and code and architecture evaporate for something simple and flexible that can actually learn and have more than few chances to become what the problem needs.
Another reality is tech folks don't need interpreters like they are sub-human or something either. It all depends how the organization and it's culture is put together to value everyone.
Where tech folks are relegated to be "engineering" it's at the peril of the organization. The more layers between the customers, their problems and those who create the solution (together), the greater the disconnect that can form as the org grows.
The solution is about a table.
A round table.
Where everyone has an equal seat and can understand it together.
I can say that tech creators tend to be able to learn product and business easier than the other way around.
One reality is too many product folks don't always know what tech is capable and possible of, which can undermine the asks and the solves. So innovation can become best practices (existing) and increments from there, instead of seeing new ways digital can be delivered.
I'm all for making fun of premature optimization and abstraction into wavy concepts. That can happen as much in product practice as it does development. Maybe the sticky consumption ratio could be part of a KPI.
When building technology solutions to solve people's problems, clever architecture will always beat clever coding and clever product people. Because you make both product and code and architecture evaporate for something simple and flexible that can actually learn and have more than few chances to become what the problem needs.
Another reality is tech folks don't need interpreters like they are sub-human or something either. It all depends how the organization and it's culture is put together to value everyone.
Where tech folks are relegated to be "engineering" it's at the peril of the organization. The more layers between the customers, their problems and those who create the solution (together), the greater the disconnect that can form as the org grows.
The solution is about a table.
A round table.
Where everyone has an equal seat and can understand it together.
I guess it’s an old story. You can’t have pure tech guys guiding the ship.
Is that the case? If so, this makes it look worse: Pure tech guys should be able to make a performant application.
The "tech guys", as you call them, are dogfooding the app and feeling the pain every day. Matthew — the CEO — is the biggest poweruser of them all and feels all the pain points, with his account being the worst-case edge case.
It's just that most of the money comes from consulting, and consulting customers care about new features, not performance or UX.
Which is btw not just a problem for Element — the other companies working on Matrix have the same issues, for the same reasons.
Discord can afford this level of UI polish because they're spending an order of magnitude more on dev salaries than the entire revenue of all companies working on matrix combined.
It's just that most of the money comes from consulting, and consulting customers care about new features, not performance or UX.
Which is btw not just a problem for Element — the other companies working on Matrix have the same issues, for the same reasons.
Discord can afford this level of UI polish because they're spending an order of magnitude more on dev salaries than the entire revenue of all companies working on matrix combined.
https://schildi.chat is better client than Elememt IMHO. That was the whole point of matrix federated. You dont hear ppl complain oh I am going to give up on SMTP cause outlook or fill in the blank sucks. Then make another client or server.
EDIT:
It really sucks that the default implementation is so bloated. But I do not equate matrix with element.
EDIT:
It really sucks that the default implementation is so bloated. But I do not equate matrix with element.
you do understand that schildichat is a relatively light fork of element…?
Ok fair. Did not know that. Just in my personal experience it is better. However like conduite for server , a lightweight http API client can be made. And communicate over https is great for crappy internet over proxy.
Can you quantify this "better"?
Exactly.
> I try to be positive and supportive of project, but my experience with these guys is that they're incredibly arrogant.
This has been my experience with many FOSS projects in general. Don't even get me started on what happens when a fork emerges.
"They don't want open source, they want to be the ONLY source."
This has been my experience with many FOSS projects in general. Don't even get me started on what happens when a fork emerges.
"They don't want open source, they want to be the ONLY source."
This statement might be ok in a generic sense, but it is unfair in a discussion of Matrix and Element. They have gone out of their way to encourage other source.
I get that you didn't say this explicitly about this particular project. I just think these folks deserve some credit.
I get that you didn't say this explicitly about this particular project. I just think these folks deserve some credit.
Got a link? What forks of element or synapse have they publicly endorsed?
https://matrix.org/ecosystem/
Lists of competing clients, servers, hosts, and more.
Lists of competing clients, servers, hosts, and more.
Not to mention the great "This Week in Matrix" RSS feed they do that I've been enjoying for years.
https://matrix.org/category/this-week-in-matrix/
Incredibly supportive of anything within the Matrix ecosystem.
https://matrix.org/category/this-week-in-matrix/
Incredibly supportive of anything within the Matrix ecosystem.
I'm of the same stance. I've been using Matrix for 3 years now, primarily to communicate with family located where there is high censorship and most messengers are blocked. Probably due to the complexity of the system and inherent design, performance is horrible. Good enough for usage but just unpleasant. Their new Element X client is meant to solve a lot of problems but they're starting to deviate from common standards (e.g. TURN/STUN for calling) and towards "Element Call" and livekit which are a nightmare to set up. There's been more and more encryption problems lately where I'd sync the keys but still fail to decrypt messages on certain clients and lose history on others. I'm sticking with the old Element client but it's obvious the Vector people aren't putting much effort into it anymore seeing as there are very old but critical bugs (main one being the fact that it automatically reaches out to matrix.org when trying to sign in with other homeservers and freezes if the domain is blocked. This is fixed by Element X.) I can fix it myself but until IOS allows sideloading, I have no way of getting my fork onto my family's devices.
If anyone knows an alternative that has web, IOS, and Android clients, easily self hostable, and can do calling, please let me know.
If anyone knows an alternative that has web, IOS, and Android clients, easily self hostable, and can do calling, please let me know.
It’s depressing to hear that you’ve given up on Element X, given that’s where all the work has been going, including ensuring the encryption is rock solid. Element Call is still webrtc; the fact it’s direct calling to a SFU rather than needing TURN for firewall traversal should be a good thing. How did you try to set it up? I did a basic walk through at https://github.com/element-hq/element-docker-demo in case that helps.
It's depressing to be told that we can pick between a moribund client and one that's barely usable, indeed.
Element X is a mess. You can make it look good in comparison to the previous one on a "checkbox" basis like you just did, but it's clunky, buggy, and so unappealing that I don't see myself recommending it to anyone. Even tech nerds can't stand it any longer, which was the premise of this post.
Yup, I get it, you are emotionally involved in all of this, and criticism hurts, but the only way "blaming it on the users" ends, is with no users left at all.
Element X is a mess. You can make it look good in comparison to the previous one on a "checkbox" basis like you just did, but it's clunky, buggy, and so unappealing that I don't see myself recommending it to anyone. Even tech nerds can't stand it any longer, which was the premise of this post.
Yup, I get it, you are emotionally involved in all of this, and criticism hurts, but the only way "blaming it on the users" ends, is with no users left at all.
are we even talking about the same app? This is literally the first time i’ve heard someone accuse Element X of being clunky, buggy or unappealing - including the original post? The criticism is that it’s not got threads/spaces, surely.
> This is literally the first time i’ve heard someone accuse Element X of being clunky, buggy or unappealing
I mean, picked from the top of THIS comments section
- https://news.ycombinator.com/item?id=44627333
- https://news.ycombinator.com/item?id=44617565
- https://news.ycombinator.com/item?id=44617604
(the linked article being a fourth)
I mean, picked from the top of THIS comments section
- https://news.ycombinator.com/item?id=44627333
- https://news.ycombinator.com/item?id=44617565
- https://news.ycombinator.com/item?id=44617604
(the linked article being a fourth)
right, so you are talking about the old legacy Element client, which all those links and the OP are complaining about being clunky/buggy/unappealing.
Not the Element X rewrite, which everyone seems to agree is better… but just not feature complete yet. Thanks for clarifying :)
Not the Element X rewrite, which everyone seems to agree is better… but just not feature complete yet. Thanks for clarifying :)
> talking about the old legacy Element client
No, out of the 4 cited sources, at least 3 clearly identify Element X. Also, great way to miss the point: users can only bear so long being told that they are wrong.
No, out of the 4 cited sources, at least 3 clearly identify Element X. Also, great way to miss the point: users can only bear so long being told that they are wrong.
Element X is (e)xcellent. Just wanted to share that.
Been using Matrix via Synapse since ~2019 and all the Matrix odds and ends require the least maintenance out of anything in the stack. Any uptime issues I've experienced have been my own silly fault with incorrect configurations.
Even Element as it stands without the X builds is leaps and bounds ahead of anything else I've tried (and I have and continue to try a lot of FOSS, but nothing does what Element does as a client, nor what Matrix does as a protocol).
Been using Matrix via Synapse since ~2019 and all the Matrix odds and ends require the least maintenance out of anything in the stack. Any uptime issues I've experienced have been my own silly fault with incorrect configurations.
Even Element as it stands without the X builds is leaps and bounds ahead of anything else I've tried (and I have and continue to try a lot of FOSS, but nothing does what Element does as a client, nor what Matrix does as a protocol).
Yep, I'm also using Element X and I'm quite happy with it.
It will be nice once all the features are in, but experience seems to indicate that I can live with better performance and fewer features.
It will be nice once all the features are in, but experience seems to indicate that I can live with better performance and fewer features.
It's depressing to see and hear that New Vector is rewriting the flagship client about every 5 years or so, with each rewrite taking multiple years. Each time the new client is hailed as the saviour, and then after a while, denounced as obsolete. Soon again, the new saviour is right around the corner.
That is not the way you create high-quality software in a cost-efficient manner.
While Matrix has a value as the pretty much only open-standard IM system with even moderate levels of user adoption, all this makes it hard to actually love it or even to be enthustiastic about it.
That is not the way you create high-quality software in a cost-efficient manner.
While Matrix has a value as the pretty much only open-standard IM system with even moderate levels of user adoption, all this makes it hard to actually love it or even to be enthustiastic about it.
The only problem with this statement is that it’s untrue.
Element Web/Desktop is 11 years old and has never been rewritten, and while we’re just starting to experiment with the Rust SDK for it, it’s unclear yet whether we migrate the current app to Rust SDK or write an Element X Web.
Element iOS is also 11 years old, and as fun and expensive as it was maintaining three entirely separate codebases between iOS/Android/Web, we only switched to Rust with Element X as of Sept, and have no plans to switch again.
Now, it’s true that Riot Android did get rewritten in ~2019 (into RiotX, which became Element Android) - mainly because it needed to get a proper storage layer and to move from Android 2.x vintage UI code. Now we have a common rust SDK to do all the heavy lifting it is reasonable to switch the app to use it, which is what Element X Android is.
In other words, this whole exercise is trying to simplify development on to one stable Rust codebase, rather than hunting bugs and reimplementing features over 3 entirely separate codebases.
If we did it again perhaps we’d try for a replace-the-engine like Signal did rather than rewrite-the-app - or perhaps do a big bang replacement when the rewrite is ready. But instead we wanted to get the new apps in the hands of users earlier, and we do not remotely have the funding to develop both old and new in parallel.
Hopefully history will show this was an okay approach in the end, even if everyone hates us in the final stages of the transition.
Element Web/Desktop is 11 years old and has never been rewritten, and while we’re just starting to experiment with the Rust SDK for it, it’s unclear yet whether we migrate the current app to Rust SDK or write an Element X Web.
Element iOS is also 11 years old, and as fun and expensive as it was maintaining three entirely separate codebases between iOS/Android/Web, we only switched to Rust with Element X as of Sept, and have no plans to switch again.
Now, it’s true that Riot Android did get rewritten in ~2019 (into RiotX, which became Element Android) - mainly because it needed to get a proper storage layer and to move from Android 2.x vintage UI code. Now we have a common rust SDK to do all the heavy lifting it is reasonable to switch the app to use it, which is what Element X Android is.
In other words, this whole exercise is trying to simplify development on to one stable Rust codebase, rather than hunting bugs and reimplementing features over 3 entirely separate codebases.
If we did it again perhaps we’d try for a replace-the-engine like Signal did rather than rewrite-the-app - or perhaps do a big bang replacement when the rewrite is ready. But instead we wanted to get the new apps in the hands of users earlier, and we do not remotely have the funding to develop both old and new in parallel.
Hopefully history will show this was an okay approach in the end, even if everyone hates us in the final stages of the transition.
I don't actually dislike the new client. It's just that things don't work well between them. Afaik you can't call someone on Element X from old element.
Aside from your valid concerns about Element roadmaps, you highlight a completely different really crummy problem. You have chosen (or have had chosen for you) the support of a closed platform that puts you in a pickle. The dev team for an app of interest to you doesn't seem to have the bandwidth to address all your concerns as quickly as would be super. But they have taken the hit to get their code into the walled garden where you can use it. You have the bandwidth to tackle some of your wishlist, but don't have access into the walled garden.
So what might be a negotiation between two parties--you and the app dev team--is now complicated by a thorny third party--your os platform team. Presumably you derive some value in other areas from your walled garden that offsets the penalty it introduces in this case. But it's still crummy that you're caught in this snag created by your os platform.
So what might be a negotiation between two parties--you and the app dev team--is now complicated by a thorny third party--your os platform team. Presumably you derive some value in other areas from your walled garden that offsets the penalty it introduces in this case. But it's still crummy that you're caught in this snag created by your os platform.
I think this misses that GP is using this to communicate with other people who use these platforms. It’s been chosen for them by their friends and family.
You can try monal xmpp. It's working great for my contacts. There are multiple servers that you can self host. On android you have better part is conversations. My entire family uses it.
> primarily to communicate with family located where there is high censorship and most messengers are blocked
I was travelling frequently through Asia and the Middle East around a decade ago. I wanted a platform that just works, that is low on resources, that I can self-host, that I can "disguise" itself as something else when needed (run behind a different port, or IP, over ToR, etc).
Matrix was new then, and promising to right every wrong from previous protocols (mild exaggeration). I bought into the hype, and got burnt by it, finally settled with XMPP (which Matrix had told me wasn't adequate), and stayed there to this day because when Matrix really didn't go anywhere since, XMPP kept getting better and better. That would be my recommendation to you.
I was travelling frequently through Asia and the Middle East around a decade ago. I wanted a platform that just works, that is low on resources, that I can self-host, that I can "disguise" itself as something else when needed (run behind a different port, or IP, over ToR, etc).
Matrix was new then, and promising to right every wrong from previous protocols (mild exaggeration). I bought into the hype, and got burnt by it, finally settled with XMPP (which Matrix had told me wasn't adequate), and stayed there to this day because when Matrix really didn't go anywhere since, XMPP kept getting better and better. That would be my recommendation to you.
The issue of broken rooms was reportedly the database having gotten corrupted indexes, which affected a bunch of rooms (2/55 of ones I was in): https://github.com/element-hq/synapse/issues/18606#issuecomm....
Not much a protocol/implementation can do about that. It did take over 2 weeks for it to be resolved though, which is a rather long period of time.
Also on the status page - https://status.matrix.org/incidents/8gljb3gtlv11 (shows start at Jul 2, but I noticed it on Jun 28)
After that was resolved, messages that were sent and received by/on other homeservers during that time never ended up on matrix.org, so much for federation :/
Not much a protocol/implementation can do about that. It did take over 2 weeks for it to be resolved though, which is a rather long period of time.
Also on the status page - https://status.matrix.org/incidents/8gljb3gtlv11 (shows start at Jul 2, but I noticed it on Jun 28)
After that was resolved, messages that were sent and received by/on other homeservers during that time never ended up on matrix.org, so much for federation :/
The corrupt room bug which pushed the OP over the edge was due to a corrupted DB index on matrix.org which caused millions of rows to be incorrectly deleted and was an absolute nightmare to debug and mitigate. You can see some of the story at https://marc.info/?t=175161814600006&r=1&w=2.
We need to write up the incident report; it’s not clear whether the root cause was a bug in postgres (potentially years ago, and only caused problems when we started using the corrupt piece of the index by coincidence) or due to potential corruption from a HW failure years ago.
The rooms affected should now work again after reconstructing the lost data. No data should have been lost over federation though; the room history should have synced up as normal. Also, only room state (not msgs) was effected. Do you have a bug report anywhere for the missing msgs?
We need to write up the incident report; it’s not clear whether the root cause was a bug in postgres (potentially years ago, and only caused problems when we started using the corrupt piece of the index by coincidence) or due to potential corruption from a HW failure years ago.
The rooms affected should now work again after reconstructing the lost data. No data should have been lost over federation though; the room history should have synced up as normal. Also, only room state (not msgs) was effected. Do you have a bug report anywhere for the missing msgs?
Thanks for the link to the postgres discussion! An incident report would definitely be interesting.
I haven't reported the missing messages thing anywhere as I assumed that was just expected (IIRC (and this is a big IIRC) it was mentioned a long time ago (i.e. entirely unrelated to this) by TravisR on Discord bridge problems as a possible cause for missing messages).
Here is one event in an affected room, made by a t2bot.io account on July 6, to which t2bot.io accounts can reply to, but which gets an "Event not found." error when requested by me, @dzaima:matrix.org: (and for reference t2bot.io functioned properly on other rooms during that time, so overall t2bot.io↔matrix.org federation should've been fine; and for reference there's a third homeserver that federated with t2bot.io fine in that room just fine too; and to be clear the room works fine now)
I haven't reported the missing messages thing anywhere as I assumed that was just expected (IIRC (and this is a big IIRC) it was mentioned a long time ago (i.e. entirely unrelated to this) by TravisR on Discord bridge problems as a possible cause for missing messages).
Here is one event in an affected room, made by a t2bot.io account on July 6, to which t2bot.io accounts can reply to, but which gets an "Event not found." error when requested by me, @dzaima:matrix.org: (and for reference t2bot.io functioned properly on other rooms during that time, so overall t2bot.io↔matrix.org federation should've been fine; and for reference there's a third homeserver that federated with t2bot.io fine in that room just fine too; and to be clear the room works fine now)
https://matrix.org/_matrix/client/v3/rooms/!WpdazzauuDxyGNAiCr:matrix.org/context/$BM9s8e3vUhk_iHfdg7D_s7CsQ5COFSPdlJdygz7TKvUHuge thanks for giving details we can investigate; i've taken a look:
* That event is in the matrix.org DB...
* ...but it failed authentication checks and got rejected from being added to matrix.org's copy of the room, presumably because matrix.org didn't think the sender was in the room at the point that the message was sent
* This was almost certainly because the state groups that tracked that the sender was in the room had been deleted due to the where clause on DELETEs matching unrelated rows thanks to the corrupted index
So the sending server probably thought it had successfully sent the message, but matrix.org quarantined it due to the db corruption. Therefore we need to manually flush the rejected messages to get them re-authorised in the impacted rooms; we hadn't spotted the problem so forgot to do so. I've nudged the folks who run the server to take a look on Monday.
Sorry you got hit by this, and thanks again for the actionable report.
* That event is in the matrix.org DB...
* ...but it failed authentication checks and got rejected from being added to matrix.org's copy of the room, presumably because matrix.org didn't think the sender was in the room at the point that the message was sent
* This was almost certainly because the state groups that tracked that the sender was in the room had been deleted due to the where clause on DELETEs matching unrelated rows thanks to the corrupted index
So the sending server probably thought it had successfully sent the message, but matrix.org quarantined it due to the db corruption. Therefore we need to manually flush the rejected messages to get them re-authorised in the impacted rooms; we hadn't spotted the problem so forgot to do so. I've nudged the folks who run the server to take a look on Monday.
Sorry you got hit by this, and thanks again for the actionable report.
FWIW, my specific room didn't lose much due to the missed syncing, I manually copied over the lost messages (..and we're used to doing so due to the flaky discord bridge). I just noted it as it seemed like a generally relevant thing (and of course perhaps more important for other affected rooms). Thanks for looking into it though, good to know that's at least not how it's supposed to function!
Wait, did anyone investigate on why messages were not stored by other homeservers? That's rather odd, given the selling point of matrix is federation
I've heard that messages not getting through federation in some cases is just a thing that can happen. How that's compatible with calling matrix as having good federation, I don't know.
I’m not aware of any scenarios, including this one, where messages don’t federate (unless the destination server has been unavailable and marked down, obviously).
No, you are making things up. That cannot happen unless the homeservers are not configured properly. If you don't have anything to back that story up, I suggest you slow down on making matrix look bad
Unfortunately I cannot find where I had read that, might've just misinterpreted discussion about delays as about dropping messages / interpreting messages as answers to questions I didn't actually post... Sorry for the unnecessary negativity!
in dzaima’s defence they did hit an instance here where messages were effectively dropped - but only because the matrix.org db was so corrupted it incorrectly quarantined them (and even then, they can be flushed through). corruot db is effectively an extreme form of misconfiguration, i guess.
We had a variation on this discussion a few days ago here
https://news.ycombinator.com/item?id=44591820
I discussed that their primary server had a child porn/child sex assault imagery problem. Others who had similar concerns were completely dismissed and attacked by the Element/Matrix admins.
I have to agree with this article. Matrix is basically dead, and not worth keeping around. And it starves the open source ecosystem from better things taking hold.
https://news.ycombinator.com/item?id=44591820
I discussed that their primary server had a child porn/child sex assault imagery problem. Others who had similar concerns were completely dismissed and attacked by the Element/Matrix admins.
I have to agree with this article. Matrix is basically dead, and not worth keeping around. And it starves the open source ecosystem from better things taking hold.
youtube has this problem, discord has this problem and many other platforms
what do those platforms do to combat child stuff? i don't like to dismiss anything but it is something all platforms and even multi billion dollar ones struggle with
eu tries to decrypt e2e chats while you can see this stuff everywhere without encryption and nothing is being done to combat this on these major platforms
as discord and whatsapp are getting shittier, i still keep it around for talking with friends, having my own server is not that hard and there are zero issues compared to main matrix.org server, just couple dollars for vle2 on ovh is sufficient
what do those platforms do to combat child stuff? i don't like to dismiss anything but it is something all platforms and even multi billion dollar ones struggle with
eu tries to decrypt e2e chats while you can see this stuff everywhere without encryption and nothing is being done to combat this on these major platforms
as discord and whatsapp are getting shittier, i still keep it around for talking with friends, having my own server is not that hard and there are zero issues compared to main matrix.org server, just couple dollars for vle2 on ovh is sufficient
The big platforms always use a variety of solutions. Always some kind of database of hashes of known CSAM available via an API. Always human beings on a trust and safety team. Takes considerable time, money, and emotional toll.
Not just anyone can access all of the SaaS databases and it's approved on a case-by-case basis. Obviously not all CSAM is in these databases, and gen AI output adds another hurdle to preventing this kind of malicious behaviour.
Personally, I feel a potential solution could be that user clients could opt into referencing hashes of media before it is downloaded, and that could either be handled by their home server, or a third-party. However, something like that is really idealism and not realistic at this point, despite being a great solution in a perfect world where people maintain encryption, yet don't expose themselves to CSAM inadvertently.
In terms of the Matrix.org homeserver, perhaps an alternative (though would prove unpopular) is only allowing Matrix.org users to upload media if they're a paying supporter of the Matrix.org homeserver with a valid payment method on their account, thus obviously linking their identity to their account.
https://matrix.org/membership/
The knock-on effect would be that it may offload some users onto their own infrastructure and alleviate the moneypit of a public instance, or directly fund the public instance itself if they do choose to support it financially. The Matrix.org instance doesn't support users adding bridges, so it isn't that much of a stretch to forbid media uploads from non-supporters. Portable identities would make this a no-brainer, but even without them, I still feel as if the public instance is largely an incredibly generous demo to help folks take Matrix for a spin. Decentralisation is such a major selling point that's vastly underutilized.
I do think that people should at least attempt to become decentralized and manage their own community by themselves, be it public or private. Large public homeservers are always going to be considerable targets for this kind of problem. It's a lot of digital eggs in one digital basket for a lot of reasons.
Nothing stopping people uploading images onto a third-party file storage system and providing the URL if they absolutely need to share a screenshot or similar on the public Matrix.org instance. Anyway, fleeting thoughts.
Not just anyone can access all of the SaaS databases and it's approved on a case-by-case basis. Obviously not all CSAM is in these databases, and gen AI output adds another hurdle to preventing this kind of malicious behaviour.
Personally, I feel a potential solution could be that user clients could opt into referencing hashes of media before it is downloaded, and that could either be handled by their home server, or a third-party. However, something like that is really idealism and not realistic at this point, despite being a great solution in a perfect world where people maintain encryption, yet don't expose themselves to CSAM inadvertently.
In terms of the Matrix.org homeserver, perhaps an alternative (though would prove unpopular) is only allowing Matrix.org users to upload media if they're a paying supporter of the Matrix.org homeserver with a valid payment method on their account, thus obviously linking their identity to their account.
https://matrix.org/membership/
The knock-on effect would be that it may offload some users onto their own infrastructure and alleviate the moneypit of a public instance, or directly fund the public instance itself if they do choose to support it financially. The Matrix.org instance doesn't support users adding bridges, so it isn't that much of a stretch to forbid media uploads from non-supporters. Portable identities would make this a no-brainer, but even without them, I still feel as if the public instance is largely an incredibly generous demo to help folks take Matrix for a spin. Decentralisation is such a major selling point that's vastly underutilized.
I do think that people should at least attempt to become decentralized and manage their own community by themselves, be it public or private. Large public homeservers are always going to be considerable targets for this kind of problem. It's a lot of digital eggs in one digital basket for a lot of reasons.
Nothing stopping people uploading images onto a third-party file storage system and providing the URL if they absolutely need to share a screenshot or similar on the public Matrix.org instance. Anyway, fleeting thoughts.
Seconds after a video is released on big yt channels bots spam the hell out of it with nasty stuff. But youtube rather fights adblockers rather than this nasty stuff. Discord is just less obvious but it is also a huge issue there
As for matrix i think non-paying user should have limited interactions in large rooms only, maybe require mod approval. There is no reason to limit personal chats or friends chat with five people.
As for matrix i think non-paying user should have limited interactions in large rooms only, maybe require mod approval. There is no reason to limit personal chats or friends chat with five people.
Non-sequitur.
> Others who had similar concerns were completely dismissed and attacked by the Element/Matrix admins.
This is completely untrue, as per https://news.ycombinator.com/item?id=44599457.
We are VERY aware of the CSAM spammer problem, and have been working solidly on it, and apologising whereever we can - e.g. https://news.ycombinator.com/item?id=44599382.
This is completely untrue, as per https://news.ycombinator.com/item?id=44599457.
We are VERY aware of the CSAM spammer problem, and have been working solidly on it, and apologising whereever we can - e.g. https://news.ycombinator.com/item?id=44599382.
I want to like matrix, but I had to give up my homeserver. For reasons that are unclear to me I was added to the matrix.org homeserver blacklist, with no communication on why or response to my asking why.
Eventually I noticed some issue with the database, it having grown many hundreds of GB (something about my users being stuck in matrix.org rooms that they're blacklisted from, I guess) so I rm -rf'd it and that's that. :\
Eventually I noticed some issue with the database, it having grown many hundreds of GB (something about my users being stuck in matrix.org rooms that they're blacklisted from, I guess) so I rm -rf'd it and that's that. :\
Could it be that your needs would be covered by XMPP? You can run that on a RPi in a shoebox.
Probably, yeah, though I'm not familiar with the ecosystem yet. It seems like ejabberd is written in erlang, which is promising.
> I'm not familiar with the ecosystem yet. It seems like ejabberd is written in erlang
I highly recommend ejabberd: it's one of the easiest server software I ever had to sysadmin. It's rock-solid and never gets in your way. It also packs everything you need for modern instant messaging and audio/video calls. Install it, open few firewall ports, define some DNS SRV records, and you are good to go.
> which is promising.
I mean, ejabberd is what WhatsApp and FB Messenger started from :-)
I highly recommend ejabberd: it's one of the easiest server software I ever had to sysadmin. It's rock-solid and never gets in your way. It also packs everything you need for modern instant messaging and audio/video calls. Install it, open few firewall ports, define some DNS SRV records, and you are good to go.
> which is promising.
I mean, ejabberd is what WhatsApp and FB Messenger started from :-)
For some particular areas of development there is strong incentive to be on matrix. For instance most ActivityPub / Fediverse related projects favor matrix. One example of a space that has a big collection of rooms here is "ActivityPub community" space [0], but there are plenty more. Also for the FOSS projects I'm interested in I find them mostly on matrix, and Discord, Zulip, or Slack are the exception (you could say that Discord/Slack are mostly chosen by OSS projects, and FOSS prefers Matrix, IRC, Zulip, XMPP).
[0] https://matrix.to/#/#activitypub-community:codelutin.com
[0] https://matrix.to/#/#activitypub-community:codelutin.com
I'd been maintaining my own Synapse homeserver for years mainly to chat with one friend, who uses the matrix.org server. Images shared between us break on a regular basis, and yes they broke for a bit during the authenticated media changeover but also since then he just periodically doesn't receive images I send.
It happened again last week, I said "fuck it, the devs will just claim it's my fault if I ask for help, let's just take this to Signal". I'll probably shut down my homeserver once I've figured out alternative ways to access the handful of communities I also happen to follow via Matrix. I have no doubt a reply will be forthcoming soon about how that's all a coincidental thing which isn't actually Matrix's fault but I've been reading those replies here for years and the actual situation doesn't improve.
It happened again last week, I said "fuck it, the devs will just claim it's my fault if I ask for help, let's just take this to Signal". I'll probably shut down my homeserver once I've figured out alternative ways to access the handful of communities I also happen to follow via Matrix. I have no doubt a reply will be forthcoming soon about how that's all a coincidental thing which isn't actually Matrix's fault but I've been reading those replies here for years and the actual situation doesn't improve.
I'm not sure where the "devs will claim it's my fault if i ask for help" trope is coming from - we really do want Matrix to work :( Do you have a bug report of where this is happening, on what set of clients? A bunch of people have been reporting images not loading, but I haven't seen anything actionable. Is it possible that this is anti-image-spam protection kicking in?
> Is it possible that this is anti-image-spam protection kicking in?
Man I can't see where the trope of developers implying it's the user's fault is coming from
Man I can't see where the trope of developers implying it's the user's fault is coming from
This also comes as the organization is preparing a coordinated update to fix 2 CVEs in the protocol [1], that were originally reported 6 months ago.
[1] https://matrix.org/blog/2025/07/security-predisclosure/
[1] https://matrix.org/blog/2025/07/security-predisclosure/
fwiw these CVEs weren’t reported 6 months ago; they were found during a project which has been running for 6 months.
Oh interesting! I guess I read that post wrong, thanks for clarifying.
I would be interested in learning more context around this issue once you are able to share, so hopefully there will be a report/post/etc after the embargo lifts.
I would be interested in learning more context around this issue once you are able to share, so hopefully there will be a report/post/etc after the embargo lifts.
My experience, contradicted when I bring it up usually (But not by this article): I've found the Element client to be slow and buggy, and I still can't figure out how to either verify my account, or get the verification notifications to go away.
I think everyone agrees that the classic Element client is slow and has a tonne of tech debt, including bad encryption UX, which is why we rebuilt it as Element X. Web /Desktop is yet to follow, although we’ve started it here: https://github.com/element-hq/aurora
"Pull requests welcome" is all I can say to anyone who puts energy into long rants about the "state" of a FOSS project.
If you think volunteer dev is so easy then get stuck in and be the change you want to see.
If you think volunteer dev is so easy then get stuck in and be the change you want to see.
Pull requests aren't going to solve the current issues with Matrix. I believe that the problem arises from the protocol design itself. And cutting back on the current specification is not viable for an already deployed project.
Here are some reasons why I think it's the protocol. Synapse is the only fully functional home server. Both dendrite and conduit are struggling to reach feature parity. This could be either due to the protocol being too complex or it being extended too fast. I have seen signs of both. Meanwhile, practically all web clients like element, cinny and schildi are all based on the same codebase. Native clients like Fractal and Nheko do exist. But it looks like they are also going to need the rust library behind elementx to attain full function. This lack of diversity among the clients are also indicative of the protocol complexity (similar to how nearly every web browser is based on Chrome's blink engine).
Here are some reasons why I think it's the protocol. Synapse is the only fully functional home server. Both dendrite and conduit are struggling to reach feature parity. This could be either due to the protocol being too complex or it being extended too fast. I have seen signs of both. Meanwhile, practically all web clients like element, cinny and schildi are all based on the same codebase. Native clients like Fractal and Nheko do exist. But it looks like they are also going to need the rust library behind elementx to attain full function. This lack of diversity among the clients are also indicative of the protocol complexity (similar to how nearly every web browser is based on Chrome's blink engine).
This is not correct.
Matrix is deliberately asymmetrical - it’s easier to write clients than servers (although that balances has shifted somewhat with E2EE).
The reason Dendrite has fallen behind is simply because we couldn’t afford to split focus between it and Synapse. Meanwhile the various Conduit projects seem to be keeping up quite well despite being entirely hobby projects.
Clientside, there are entirely separate production grade stacks with full featuresets in at least typescript (eg Element Web), rust (EX, Fractal), Dart (FluffyChat), KMP (Trixnity), C++ (Nheko), Go (Beeper) and more. I can guarantee their authors would very heavily push back on the “you need rust-sdk to attain full function”, not least as many of those have more features than rust-sdk.
This is not a WebKit situation.
Matrix is deliberately asymmetrical - it’s easier to write clients than servers (although that balances has shifted somewhat with E2EE).
The reason Dendrite has fallen behind is simply because we couldn’t afford to split focus between it and Synapse. Meanwhile the various Conduit projects seem to be keeping up quite well despite being entirely hobby projects.
Clientside, there are entirely separate production grade stacks with full featuresets in at least typescript (eg Element Web), rust (EX, Fractal), Dart (FluffyChat), KMP (Trixnity), C++ (Nheko), Go (Beeper) and more. I can guarantee their authors would very heavily push back on the “you need rust-sdk to attain full function”, not least as many of those have more features than rust-sdk.
This is not a WebKit situation.
Matrix is not a some sort of volunteer project. It is used by NATO as their NI2CE, as well as by many other governmental entities. Matrix runs on European taxpayer's money.
The Matrix Foundation is currently massively underfunded (contributing significantly to many of the complaints in this thread, especially around Trust & Safety) and even then losing money. It gets no money from folks like France or NATO despite their use of Matrix. You can see the list of financially contributing projects at https://matrix.org/support - there are only two governmental entities who support Matrix directly today; Gematik in Germany and another unlisted European govt.
Element on the other hand does have a bunch of customers like NATO, but is also losing money, thanks to governmental Matrix deals often going to system integrators who win contracts with Element's FOSS software and then don't contribute any $ back to Element. I explained the mess at FOSDEM: https://youtu.be/lkCKhP1jxdk?t=740 and there's a good article about a typical instance of this (in German) at https://www.heise.de/news/Wie-Behoerden-und-ihre-Auftragnehm...
(by the way, you seem to spend a a lot of time telling everyone how shit Matrix is; don't you have anything better to do? :)
Element on the other hand does have a bunch of customers like NATO, but is also losing money, thanks to governmental Matrix deals often going to system integrators who win contracts with Element's FOSS software and then don't contribute any $ back to Element. I explained the mess at FOSDEM: https://youtu.be/lkCKhP1jxdk?t=740 and there's a good article about a typical instance of this (in German) at https://www.heise.de/news/Wie-Behoerden-und-ihre-Auftragnehm...
(by the way, you seem to spend a a lot of time telling everyone how shit Matrix is; don't you have anything better to do? :)
> thanks to governmental Matrix deals often going to system integrators who win contracts with Element's FOSS software and then don't contribute any $ back to Element
Are they contributing code? Money (explicitly to a single specific entity, especially) is hardly the only way to support something.
Are they contributing code? Money (explicitly to a single specific entity, especially) is hardly the only way to support something.
France has contributed back some code in lieu of money, but it’s a very mixed blessing given we then have to maintain that code, which costs way more in the long term than writing it in the first place. It also actively damages the braintrust of the team if Element has to let staff go because we can’t pay them, and get code instead (as happened with France).
If those contributions are more a liability than an asset, why not reject them?
We do, in some instances
> The Matrix Foundation is currently massively underfunded (contributing significantly to many of the complaints in this thread, especially around Trust & Safety) and even then losing money. It gets no money from folks like France or NATO despite their use of Matrix. You can see the list of financially contributing projects at https://matrix.org/support - there are only two governmental entities who support Matrix directly today; Gematik in Germany and another unlisted European govt.
That some specific organization is underfunded does not mean that whole Matrix was built by a few volunteer developers here and there.
> Element on the other hand does have a bunch of customers like NATO, but is also losing money, thanks to governmental Matrix deals often going to system integrators who win contracts with Element's FOSS software and then don't contribute any $ back to Element. I explained the mess at FOSDEM: https://youtu.be/lkCKhP1jxdk?t=740 and there's a good article about a typical instance of this (in German) at https://www.heise.de/news/Wie-Behoerden-und-ihre-Auftragnehm...
That's kind of the point of FOSS. Everyone can crete their own forks, and do not have a duty to contribute money, especially not to an another for-profit company. That happens to all major Free Software projects. Many users of, say, Linux kernel, do not contribute any money at all. Some even refuse to abide by the GPL license (which is less okay), but Linux still not only survives, but thrives.
> (by the way, you seem to spend a a lot of time telling everyone how shit Matrix is; don't you have anything better to do? :)
What is a "lot of time"? A few short messages online?
I think I have explained a realistic user perspective on Matrix. It works, but it has some problems. I have even told that the abuse spam problem has been gotten under control, in the recent threads concerning that.
You have gotten to the point where people care about Matrix. That's a big deal. Matrix is quite possibly a bigger thing now than IRC was at its very peak. That is a big achievement. Unless there is something big I don't know about, your situation is far from hopeless. There is no need to play a victim, give up or to start insulting your users.
The idea that citizens should just shut up about a software project partially built on public money is completely ludicrous.
That some specific organization is underfunded does not mean that whole Matrix was built by a few volunteer developers here and there.
> Element on the other hand does have a bunch of customers like NATO, but is also losing money, thanks to governmental Matrix deals often going to system integrators who win contracts with Element's FOSS software and then don't contribute any $ back to Element. I explained the mess at FOSDEM: https://youtu.be/lkCKhP1jxdk?t=740 and there's a good article about a typical instance of this (in German) at https://www.heise.de/news/Wie-Behoerden-und-ihre-Auftragnehm...
That's kind of the point of FOSS. Everyone can crete their own forks, and do not have a duty to contribute money, especially not to an another for-profit company. That happens to all major Free Software projects. Many users of, say, Linux kernel, do not contribute any money at all. Some even refuse to abide by the GPL license (which is less okay), but Linux still not only survives, but thrives.
> (by the way, you seem to spend a a lot of time telling everyone how shit Matrix is; don't you have anything better to do? :)
What is a "lot of time"? A few short messages online?
I think I have explained a realistic user perspective on Matrix. It works, but it has some problems. I have even told that the abuse spam problem has been gotten under control, in the recent threads concerning that.
You have gotten to the point where people care about Matrix. That's a big deal. Matrix is quite possibly a bigger thing now than IRC was at its very peak. That is a big achievement. Unless there is something big I don't know about, your situation is far from hopeless. There is no need to play a victim, give up or to start insulting your users.
The idea that citizens should just shut up about a software project partially built on public money is completely ludicrous.
You're thinking of Element: https://element.io/case-studies/nato
Now do Nextcloud and many other projects.
It's FOSS. There are volunteer contributors.
https://matrix.org/blog/2025/06/dispelling-myths/
> Matrix is not just an open standard for secure communication, it’s an openly governed and collaboratively developed ecosystem of projects powered by a growing community of volunteers and vendors. In this way, Matrix exemplifies the open source ethos, encourages greater innovation, and defies those who would try to build businesses based on extractive behavior and vendor lock-in.
Oh look, more calls for volunteers, despite "running on European taxpayer money": https://conference.matrix.org/volunteer/
Sorry, but idiotic remarks like this stink of having an agenda.
You don't even put a name and identity to your HN account and provide zero sources. At best, you're clueless, at worst you're spreading FUD.
Now do Nextcloud and many other projects.
It's FOSS. There are volunteer contributors.
https://matrix.org/blog/2025/06/dispelling-myths/
> Matrix is not just an open standard for secure communication, it’s an openly governed and collaboratively developed ecosystem of projects powered by a growing community of volunteers and vendors. In this way, Matrix exemplifies the open source ethos, encourages greater innovation, and defies those who would try to build businesses based on extractive behavior and vendor lock-in.
Oh look, more calls for volunteers, despite "running on European taxpayer money": https://conference.matrix.org/volunteer/
Sorry, but idiotic remarks like this stink of having an agenda.
You don't even put a name and identity to your HN account and provide zero sources. At best, you're clueless, at worst you're spreading FUD.
Oh, it seems you are here to just troll and insult everyone. Matrix by calling it just a some sort of volunteer project run by nerds in basements, and those too, who are not pleased with it's problems.
What exactly does have a "call for volunteers" to haul around stuff in a some sort of conference has to do with anything? What has Nextcloud to do with this?
You'd have known that Matrix ecosystem has lots of paid professionals working on it, if you made even a cursory research on the subject before starting to write cheeky comments.
You claimed the problems with Matrix can be solved with a few pull requests. It's your duty to back it up.
What exactly does have a "call for volunteers" to haul around stuff in a some sort of conference has to do with anything? What has Nextcloud to do with this?
You'd have known that Matrix ecosystem has lots of paid professionals working on it, if you made even a cursory research on the subject before starting to write cheeky comments.
You claimed the problems with Matrix can be solved with a few pull requests. It's your duty to back it up.
Nowhere did I say "a few pull requests". I said "pull requests welcome".
Every accusation is a confession—you are the troll.
If you are insulted then that is on you.
Name these paid professionals.
Every accusation is a confession—you are the troll.
If you are insulted then that is on you.
Name these paid professionals.
Element X works very well for my use case. My only complaint is that for some reason I’m unable to search through my messages. Even in private chats, there’s no such thing as search.
We're on the case :) https://github.com/matrix-org/matrix-rust-sdk/issues/5350
Hey Matthew, thanks for the feedback! I didn’t know how to properly search for this to learn more. Wish you for this task to succeed. It feels it’s more complicated than I thought, because of the federation and maybe encryption too, I assume.
I agree with all of it. I abandoned Matrix about a year ago and never looked back. Something's very smelly about their history, broken promises and overall quality.
I find Signal just unbeatable on all fronts: security, UX, ease of use, general thoughtfulness put into the product. It has the best simple media editor (for video clipping, blurring faces, compressing) I have ever seen casually built into the sending flow.
Every time I use anything, from MS Teams to Whatsapp, I find myself wishing they were more like Signal.
Every time I use anything, from MS Teams to Whatsapp, I find myself wishing they were more like Signal.
My main problem with Signal is that it's a mobile app with a desktop companion app. Ideally, I would prefer a federated messenger, but I would be completely fine with Signal if it wasn't a mobile-only app (you can't use the desktop version without first having the mobile app).
And it forces you to have a number.
Signal is the worst of them all when it comes to self hosting.
For me Signal is not an option. Any pretty promise can be broken on a whim in the same fashion Facebook acquired WhatsApp and could then do whatever they wanted with it. Any pretence of user-friendliness has been defeated when Signal started pushing their crypto and bar their users from using an alternative client. Centralised services are problematic by design, and almost always abusive.
No desktop web app. Makes it very annoying to engage in longer conversations on machines where I'm limited in what I can install.
tested signal years ago and the desktop client was literally unusable, would take major redesign to fix so i am assuming it is not better
To add to the pile:
- The web client doesn't load any images/media anymore for me in new sessions. I log in, I cross authenticate with another client, no images load. At work I've a very old browser session going and everything works.
- We host synapse at work to explore feasibility. Been going on for about 9 months now. Public profile lookup is disabled. This breaks inviting anyone from our company from another server, when the inviting user is using element. Because element tries to query the user info first, and if that fails with an unexpected error code, it will not allow you to continue sending the invitation. There's obviously an issue open for months now, where multiple people suggested they just add a warning that it couldn't check if the user exists, with a "continue anyways" button, but the devs prefer to come up with idiotic excuses why that would be a bad idea.
I did some quick research myself then, and it looks like the profile lookup is relayed through the server of the inviting user to the server of the user to be invited. The inviter's server converts any http error code from the invitee's server that is "not valid" to a generic error, that element then chokes on, here: https://github.com/element-hq/synapse/blob/1920dfff40ad10780...
i.e. Only 404 is valid, according to code and comment there.
But IN THE SAME FUCKING SOURCE FILE, they return a 403 if profile lookup is disabled: https://github.com/element-hq/synapse/blob/1920dfff40ad10780...
Can't get any better than this I guess. Cobbled together bullshit. I hope my company will consider this experiment failed soon and switch to slack or something. Anything.
- The web client doesn't load any images/media anymore for me in new sessions. I log in, I cross authenticate with another client, no images load. At work I've a very old browser session going and everything works.
- We host synapse at work to explore feasibility. Been going on for about 9 months now. Public profile lookup is disabled. This breaks inviting anyone from our company from another server, when the inviting user is using element. Because element tries to query the user info first, and if that fails with an unexpected error code, it will not allow you to continue sending the invitation. There's obviously an issue open for months now, where multiple people suggested they just add a warning that it couldn't check if the user exists, with a "continue anyways" button, but the devs prefer to come up with idiotic excuses why that would be a bad idea.
I did some quick research myself then, and it looks like the profile lookup is relayed through the server of the inviting user to the server of the user to be invited. The inviter's server converts any http error code from the invitee's server that is "not valid" to a generic error, that element then chokes on, here: https://github.com/element-hq/synapse/blob/1920dfff40ad10780...
i.e. Only 404 is valid, according to code and comment there.
But IN THE SAME FUCKING SOURCE FILE, they return a 403 if profile lookup is disabled: https://github.com/element-hq/synapse/blob/1920dfff40ad10780...
Can't get any better than this I guess. Cobbled together bullshit. I hope my company will consider this experiment failed soon and switch to slack or something. Anything.
> The web client doesn't load any images/media anymore for me in new sessions. I log in, I cross authenticate with another client, no images load. At work I've a very old browser session going and everything works.
That sounds like something with authenticated media has gone really wrong.
Do the fetch requests for the media fail, or does it not even attempt to make the requests? Is there an error message in the logs?
Regarding the invite issue, could you please clarify in which versions of element (web/desktop, android, iOS, elementX) you've seen the issue, and in which dialogs (search for user, create new room, invite users to existing room)?
That sounds like something with authenticated media has gone really wrong.
Do the fetch requests for the media fail, or does it not even attempt to make the requests? Is there an error message in the logs?
Regarding the invite issue, could you please clarify in which versions of element (web/desktop, android, iOS, elementX) you've seen the issue, and in which dialogs (search for user, create new room, invite users to existing room)?
Media loading fails with M_NOT_FOUND (debug console network tab), regardless of wehter the user posting the image is from my own home server or another one.
Invite issue: https://github.com/element-hq/element-web/issues/29028
And several ones opened against synapse, but as it happens a fix was finally merged a day ago: https://github.com/element-hq/synapse/pull/18696
Invite issue: https://github.com/element-hq/element-web/issues/29028
And several ones opened against synapse, but as it happens a fix was finally merged a day ago: https://github.com/element-hq/synapse/pull/18696
Here's what I wrote in 2019 (https://news.ycombinator.com/item?id=21592195):
"The reason for Slack's success is probably because it's a "turn key solution": you register your company, invite your employees, enter your CC, and you're good to go."
"With a lot of these open solutions things are more complex. I think we should really focus on providing a good UX here if we want more adoption."
This seems unchanged, or even worse. Arathorn recommended modular.im in a reply, which now redirects to https://element.io/pricing, and "set up a server" just redirects to GitHub, and the only other option is "Talk to an expert" – yeah, no.
Self-hosting is great but realistically, lots of people are just not interested, and that's fine too. And even if they are: having a simple option to quickly evaluate $the_thing is probably a good idea.
This is of course in addition to all the technical problems outlined in this post, which I also reported in 2019: "opening https://riot.im/app/ makes Firefox use 100% CPU and my laptops fan spin; I closed it after 10 seconds of just a loading animation"
"The reason for Slack's success is probably because it's a "turn key solution": you register your company, invite your employees, enter your CC, and you're good to go."
"With a lot of these open solutions things are more complex. I think we should really focus on providing a good UX here if we want more adoption."
This seems unchanged, or even worse. Arathorn recommended modular.im in a reply, which now redirects to https://element.io/pricing, and "set up a server" just redirects to GitHub, and the only other option is "Talk to an expert" – yeah, no.
Self-hosting is great but realistically, lots of people are just not interested, and that's fine too. And even if they are: having a simple option to quickly evaluate $the_thing is probably a good idea.
This is of course in addition to all the technical problems outlined in this post, which I also reported in 2019: "opening https://riot.im/app/ makes Firefox use 100% CPU and my laptops fan spin; I closed it after 10 seconds of just a loading animation"
i ran a matrix homeserver for just shy of 4 years and it was the lowest user, highest maintenance service i have ever ran. thats completely putting aside the user experience issues too
the amount of spec change proposals over the years is wild: https://0x0.st/H8h-.png
this is a good thing, right? spec change proposals is how the spec evolves - they literally turn into PRs to the spec.
Is there a graph for post-2022 data? I wonder if it kept its trajectory.
sure, i just genned a new one for you: https://matrix.org/~matthew/mscs.png
The trajectory is the same, although obviously it's not ideal that the backlog grows at roughly the same rate as we merge/close them. Perhaps some day the Foundation will have enough $ to actually fund the spec core team to work on MSC review as their dayjob; meanwhile it's done in spare time or smuggled in as part of their dayjob.
Meanwhile, the fact that MSCs are being opened as fast as ever shows that folks are trying to nudge the protocol along as much as ever.
The trajectory is the same, although obviously it's not ideal that the backlog grows at roughly the same rate as we merge/close them. Perhaps some day the Foundation will have enough $ to actually fund the spec core team to work on MSC review as their dayjob; meanwhile it's done in spare time or smuggled in as part of their dayjob.
Meanwhile, the fact that MSCs are being opened as fast as ever shows that folks are trying to nudge the protocol along as much as ever.
Thank you! :)
Yeah, Matrix UX is disgusting in every aspect.
Every client looks bad, works slow and most of them have only subset of features.
At 2025 year I still can't see online status when I use most popular server and client.
When I use SDK as a developer, *I can't use encryption* for bots. I've created issue about it over year ago https://github.com/turt2live/matrix-bot-sdk/issues/363 and maintainer just closed it as not planned to fix.
Matrix Protocol is overcomplicated and ridiculous. As I understood, the reason of mentioned problem with lack of "online status" feature is a high network load that yields by presence status feature, so server owners just disable this feature.
It is ridiculous that messenger who state it is "privacy focused" - can't handle encryption for bots and sell us idea that it's fine to log-in in my account on random site on internet. Because any site where i enter my password and secret key, may steal my password.
The same thing with applications. "Reference implementation" of app is an Electron app that loads javascript from internet and may inject malware anytime.
My impression is that Matrix is a scam to spy over people who blindly believe in security, like a Telegram does.
Every client looks bad, works slow and most of them have only subset of features.
At 2025 year I still can't see online status when I use most popular server and client.
When I use SDK as a developer, *I can't use encryption* for bots. I've created issue about it over year ago https://github.com/turt2live/matrix-bot-sdk/issues/363 and maintainer just closed it as not planned to fix.
Matrix Protocol is overcomplicated and ridiculous. As I understood, the reason of mentioned problem with lack of "online status" feature is a high network load that yields by presence status feature, so server owners just disable this feature.
It is ridiculous that messenger who state it is "privacy focused" - can't handle encryption for bots and sell us idea that it's fine to log-in in my account on random site on internet. Because any site where i enter my password and secret key, may steal my password.
The same thing with applications. "Reference implementation" of app is an Electron app that loads javascript from internet and may inject malware anytime.
My impression is that Matrix is a scam to spy over people who blindly believe in security, like a Telegram does.
The last statement is totally uncalled for. Yes, matrix is not convenient and given it's far from ideal chat experience but that doesn't mean you are allowed to spread FUD. Matrix spec, clients, homeservers, etc are fully open source. No one is "scamming" anyone
No horses in this race for or against the Matrix group, but convenience, adoptability is a fair factor to look at in software, especially collaboration and interaction based software.
Matrix community scam everyone when claim a matrix is a privacy-focused. And you are part of this community who deceive people. The fact that anything is open source is not make it "privacy focused".
Literally everything in Matrix is designed against privacy and security. Check issue I mention above. The product that is "privacy focused" would never have such type of problems that will force developers to say that lack of encryption for chats is a minor problem that will not be fixed.
Literally everything in Matrix is designed against privacy and security. Check issue I mention above. The product that is "privacy focused" would never have such type of problems that will force developers to say that lack of encryption for chats is a minor problem that will not be fixed.
your issue is complaining that matrix-bot-sdk can’t exfiltrate encryption keys which predate it joining a room? this feels like a pretty reasonable limitation. if you really need this, use matrix-rust-sdk with MSC4268 enabled.
No, as i wrote in issue title and explained twice in this thread, the problem is bot SDK does not support encryption. It must work by default, for "privacy focused" application. Chat with no encryption must be an option, not default.
Matrix protocol is over-complicated, as consequence any SDK and even clients are over-complicated too, that eventually makes any interaction with Matrix is difficult, unpleasant, and error-prone.
Matrix design is error-prone by its nature:
Keys exchange confuses many users, I had many questions of people who are not programmer.
Matrix encourage login at random sites who up their web client, that is critical security problem.
But a Matrix fans are blind to a problems. This is why I don't believe Matrix will transform from marginal chat for freaks to a mainstream chat where people talk. So eventually, Matrix is a platform where Matrix fans talks about Matrix and send porn to each other.
Matrix protocol is over-complicated, as consequence any SDK and even clients are over-complicated too, that eventually makes any interaction with Matrix is difficult, unpleasant, and error-prone.
Matrix design is error-prone by its nature:
Keys exchange confuses many users, I had many questions of people who are not programmer.
Matrix encourage login at random sites who up their web client, that is critical security problem.
But a Matrix fans are blind to a problems. This is why I don't believe Matrix will transform from marginal chat for freaks to a mainstream chat where people talk. So eventually, Matrix is a platform where Matrix fans talks about Matrix and send porn to each other.
matrix-bot-sdk does support encryption: https://turt2live.github.io/matrix-bot-sdk/tutorial-encrypti...
Check discussion in GitHub issue https://github.com/turt2live/matrix-bot-sdk/issues/363
Quote > Decryption of messages in encrypted rooms always end with error `Error: Can't find the room key to decrypt the event`
Maintainer action is "turt2live closed this as not planned on May 10, 2024"
It's all you need to know about a goals of Matrix and its success.
Quote > Decryption of messages in encrypted rooms always end with error `Error: Can't find the room key to decrypt the event`
Maintainer action is "turt2live closed this as not planned on May 10, 2024"
It's all you need to know about a goals of Matrix and its success.
Would be interested to hear about alternatives.
Are you deliberately using QR only for your contact details?
Speaking as project lead for Matrix, I obviously feel pretty gutted when someone gives up like this. Doubly so when the straw that broke their back wasn't even a Matrix problem, but really gnarly postgres corruption (see https://news.ycombinator.com/item?id=44618702).
Firstly, I'm sorry they had such a bad time, and as per https://news.ycombinator.com/item?id=44621077 there's a tonne of things we've (i've) done wrong.
That said, there's a bunch of points raised here which aren't fully accurate. So for the sake of completeness:
> The official Matrix homeserver, Synapse, was built with a tech stack ill-suited for its long-term goals and scale
These days Synapse is hybrid Rust for the fast paths (https://github.com/element-hq/synapse/tree/develop/rust) and Python 3 + mypy for the rest. Huge servers like matrix.org (150K concurrent users) run fine on it. I'm not convinced the "ill-suited tech stack" crit holds.
> Community projects like Dendrite emerged to rewrite the homeserver more sensibly
Dendrite is not a community project and never has been; it was written by the core Matrix team, and then when we realised Synapse had critical mass we backported most of its architectural improvements to Synapse.
> New Vector seems to be chasing too many goals simultaneously, with no clear direction
No? we killed all the sidequests in order to just do Element Web, Element X, Element Call and Synapse.
> Just a few months ago, they migrated to the Matrix Authentication Service (MAS), which was supposed to be a leap forward, yet lacks even essential security features like 2FA/MFA.
No? the whole point of MAS is that it lets you delegate straight through to a proper IDP which provides 2FA/MFA/Passkeys etc.
> Launching the app requires network synchronization that hampers responsiveness
No? Turn off your network, launch Element X, and see that it launches fine? Obviously it does need to talk to the server to retrieve new data. I guess there was the https://github.com/element-hq/element-x-ios/issues/4102 issue, but that was fixed 3 weeks ago.
> The Matrix.org service, especially its matrix.org homeserver, is also slow
matrix.org feels pretty good to me these days, even on my mammoth account (other than when talking in Matrix HQ)
> On my laptop, I’ve been using iamb, a TUI Matrix client, and even there I experience delays of tens of seconds when launching it, and a lag of several seconds between pressing Enter and seeing the message actually appear in the chat room.
I'm assuming that's because iamb hasn't enabled sliding sync, and/or hasn't implemented local echo, or has some other perf bug. Or perhaps you're on an old build. Given it's using the same matrix-rust-sdk as Element X it should in theory be instant.
> And that’s certainly not iamb’s fault, because it’s written in Rust, btw™.
...
> the lack of proper first-party libraries for 3rd-party developers to build on top of, it became visible that the once-vibrant ecosystem, does no longer look so healthy
This is really weird. It's not clear that the Matrix Foundation should publish software at all, to be honest - it's effectively a standards body. W3C doesn't write browsers or web servers any more, for instance.
As it happens, we have invested a huge amount of effort into publishing a flagship first-party client SDK anyway: matrix-rust-sdk. And matrix-js-sdk is still there too. We very deliberately have handed off other SDKs to the broader community to maintain, which they do a great job of. Surely the fact that go-matrix got surpassed by Tulir's superior go-mautrix fork is a good thing, not a bad thing?
> Development on Synapse alternatives has stagnated
The conduits seem as active as ever, from what I can see, even if there's been forking.
Dendrite development has stalled, but this reflects lack of funding rather than the ecosystem failing, and the core team at Element having to put all its effort it into one server (Synapse) rather than splitting between two.
> Other clients like SchildiChat are faced with the dilemma of continuing their existing work or starting over by forking Element X
That's just false? SchildiChat seems to have quite happily forked EX into SchildiChat Next years ago and looks to be doing a great job of it; ahead of EX itself with many features (e.g. it already has spaces!)
> Speaking of SDKs, New Vector appears to lack a coherent technology strategy. They’ve built infrastructure in Python and Node.js/TypeScript, moved into Go for the Synapse replacement, and now maintain a Rust-based client SDK, while abandoning their Go client library (which is now community-maintained).
NV's stack is Python+Rust and Node/TS on the serverside, and Rust + (TS/Swift/Kotlin) on the clientside. It's true that over 11 years of work we've also sprouted a few Go projects (e.g. complement), and there's even some Perl (sytest), but that is very much the minority.
> Especially for an organization that appears perpetually cash-strapped. New Vector’s approach feels more like indecisiveness than the right tool for the right job when looking through their repositories on GitHub.
It feels unfortunate that the OP is complaining that NV doesn't provide enough 1st party implementations in different languages any more, while also complaining NV has too many languages in use.
> Matthew, if you’re reading this: We both know that naming things is one of the hardest problems in computer science, right after cache invalidation. I totally get the geeky, 31337 thrill a name like Matrix might evoke, but believe me when I say that using generic names is a bad idea. Things would have been a lot easier for everyone involved if you had at least rebranded Riot to something more distinctive. For future rebrandings, I highly recommend using the Synthwave Band Name Generator and some good old human creativity. :-)
Honestly Matrix & Element seem to get quite a lot of traction and successful press despite the generic names. For instance, I just spun up Tor and googled the word Element, and Element.io came up as the 2nd hit after the skateboard brand (and the whole sidebar). The data just doesn't back up this particular criticism.
Overall, though, I get why the OP is frustrated and has given up. All I can say is that we're working away on getting Element X to parity with Element as fast as we can so we can retire the 'classic' app, at which point I think much of the pain people are experiencing will go away. It's taking longer than I'd like given the work is entangled with building and deploying government messaging systems as a way to keep the lights on, but if anything all the negativity here makes me more determined and stubborn to keep plugging away to dig out of the transitional period we're in, and get back on track.
Firstly, I'm sorry they had such a bad time, and as per https://news.ycombinator.com/item?id=44621077 there's a tonne of things we've (i've) done wrong.
That said, there's a bunch of points raised here which aren't fully accurate. So for the sake of completeness:
> The official Matrix homeserver, Synapse, was built with a tech stack ill-suited for its long-term goals and scale
These days Synapse is hybrid Rust for the fast paths (https://github.com/element-hq/synapse/tree/develop/rust) and Python 3 + mypy for the rest. Huge servers like matrix.org (150K concurrent users) run fine on it. I'm not convinced the "ill-suited tech stack" crit holds.
> Community projects like Dendrite emerged to rewrite the homeserver more sensibly
Dendrite is not a community project and never has been; it was written by the core Matrix team, and then when we realised Synapse had critical mass we backported most of its architectural improvements to Synapse.
> New Vector seems to be chasing too many goals simultaneously, with no clear direction
No? we killed all the sidequests in order to just do Element Web, Element X, Element Call and Synapse.
> Just a few months ago, they migrated to the Matrix Authentication Service (MAS), which was supposed to be a leap forward, yet lacks even essential security features like 2FA/MFA.
No? the whole point of MAS is that it lets you delegate straight through to a proper IDP which provides 2FA/MFA/Passkeys etc.
> Launching the app requires network synchronization that hampers responsiveness
No? Turn off your network, launch Element X, and see that it launches fine? Obviously it does need to talk to the server to retrieve new data. I guess there was the https://github.com/element-hq/element-x-ios/issues/4102 issue, but that was fixed 3 weeks ago.
> The Matrix.org service, especially its matrix.org homeserver, is also slow
matrix.org feels pretty good to me these days, even on my mammoth account (other than when talking in Matrix HQ)
> On my laptop, I’ve been using iamb, a TUI Matrix client, and even there I experience delays of tens of seconds when launching it, and a lag of several seconds between pressing Enter and seeing the message actually appear in the chat room.
I'm assuming that's because iamb hasn't enabled sliding sync, and/or hasn't implemented local echo, or has some other perf bug. Or perhaps you're on an old build. Given it's using the same matrix-rust-sdk as Element X it should in theory be instant.
> And that’s certainly not iamb’s fault, because it’s written in Rust, btw™.
...
> the lack of proper first-party libraries for 3rd-party developers to build on top of, it became visible that the once-vibrant ecosystem, does no longer look so healthy
This is really weird. It's not clear that the Matrix Foundation should publish software at all, to be honest - it's effectively a standards body. W3C doesn't write browsers or web servers any more, for instance.
As it happens, we have invested a huge amount of effort into publishing a flagship first-party client SDK anyway: matrix-rust-sdk. And matrix-js-sdk is still there too. We very deliberately have handed off other SDKs to the broader community to maintain, which they do a great job of. Surely the fact that go-matrix got surpassed by Tulir's superior go-mautrix fork is a good thing, not a bad thing?
> Development on Synapse alternatives has stagnated
The conduits seem as active as ever, from what I can see, even if there's been forking.
Dendrite development has stalled, but this reflects lack of funding rather than the ecosystem failing, and the core team at Element having to put all its effort it into one server (Synapse) rather than splitting between two.
> Other clients like SchildiChat are faced with the dilemma of continuing their existing work or starting over by forking Element X
That's just false? SchildiChat seems to have quite happily forked EX into SchildiChat Next years ago and looks to be doing a great job of it; ahead of EX itself with many features (e.g. it already has spaces!)
> Speaking of SDKs, New Vector appears to lack a coherent technology strategy. They’ve built infrastructure in Python and Node.js/TypeScript, moved into Go for the Synapse replacement, and now maintain a Rust-based client SDK, while abandoning their Go client library (which is now community-maintained).
NV's stack is Python+Rust and Node/TS on the serverside, and Rust + (TS/Swift/Kotlin) on the clientside. It's true that over 11 years of work we've also sprouted a few Go projects (e.g. complement), and there's even some Perl (sytest), but that is very much the minority.
> Especially for an organization that appears perpetually cash-strapped. New Vector’s approach feels more like indecisiveness than the right tool for the right job when looking through their repositories on GitHub.
It feels unfortunate that the OP is complaining that NV doesn't provide enough 1st party implementations in different languages any more, while also complaining NV has too many languages in use.
> Matthew, if you’re reading this: We both know that naming things is one of the hardest problems in computer science, right after cache invalidation. I totally get the geeky, 31337 thrill a name like Matrix might evoke, but believe me when I say that using generic names is a bad idea. Things would have been a lot easier for everyone involved if you had at least rebranded Riot to something more distinctive. For future rebrandings, I highly recommend using the Synthwave Band Name Generator and some good old human creativity. :-)
Honestly Matrix & Element seem to get quite a lot of traction and successful press despite the generic names. For instance, I just spun up Tor and googled the word Element, and Element.io came up as the 2nd hit after the skateboard brand (and the whole sidebar). The data just doesn't back up this particular criticism.
Overall, though, I get why the OP is frustrated and has given up. All I can say is that we're working away on getting Element X to parity with Element as fast as we can so we can retire the 'classic' app, at which point I think much of the pain people are experiencing will go away. It's taking longer than I'd like given the work is entangled with building and deploying government messaging systems as a way to keep the lights on, but if anything all the negativity here makes me more determined and stubborn to keep plugging away to dig out of the transitional period we're in, and get back on track.
Love Matrix/Element and how you deal with criticism.
I've heard (and tried) the new experimental webapp. Is that actually something more than an experiment and will this see further development?
I'm asking because I really enjoyed it but felt like it might have been just a test balloon.
I've heard (and tried) the new experimental webapp. Is that actually something more than an experiment and will this see further development?
I'm asking because I really enjoyed it but felt like it might have been just a test balloon.
thanks :) we're still experimenting with whether to replace Element Web's engine with matrix-rust-sdk, or move Element Web's UI components over to the Aurora experiment and build an Element X Web. Given how well the Element->Element X transition is going on mobile (c.f. the rest of this thread) you can see why we're considering our options.
So, at the moment it's very much still a test balloon (and we've yet to find anyone to fund us to do an Element X Web anyway).
So, at the moment it's very much still a test balloon (and we've yet to find anyone to fund us to do an Element X Web anyway).
This link has 71 comments and 84 points and is from 4 hours ago yet it shows for me on place 197 (page 7) of HN.
Is Ycombinator (or one of the intermediary investment funds) invested in New Vector?
Is Ycombinator (or one of the intermediary investment funds) invested in New Vector?
neither YC nor any YC-intermediary is an investor in NV. Instead, you're likely seeing that HN has circuit-breakers against high-temperature threads which turn into pile-ons (whether they're justified or not).
I try to be positive and supportive of project, but my experience with these guys is that they're incredibly arrogant.
It's tough finding an open-standards based IM application for corporate use.
XMPP is kinda fragmented, with no nice clients. Matrix is a clusterfuck with a BDFL who is probably too smart for his own good. Signal is open source but hostile towards self hosting.
P.S I suspect the organization is being led by Architecture Astronauts [1]. Every (including the naming) is abstracted to the point of meaninglessness.
[1] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...