Giving Up on Element and Matrix.org
xn--gckvb8fzb.com
xn--gckvb8fzb.com
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...
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.
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.
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 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 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 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".
(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.)
This is more of a question of enough clarity, direction and alignment.
Either both groups have it, or they don't.
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 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.
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.
EDIT:
It really sucks that the default implementation is so bloated. But I do not equate matrix with element.
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."
I get that you didn't say this explicitly about this particular project. I just think these folks deserve some credit.
Lists of competing clients, servers, hosts, and more.
https://matrix.org/category/this-week-in-matrix/
Incredibly supportive of anything within the Matrix ecosystem.
If anyone knows an alternative that has web, IOS, and Android clients, easily self hostable, and can do calling, please let me know.
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.
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)
Not the Element X rewrite, which everyone seems to agree is better… but just not feature complete yet. Thanks for clarifying :)
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.
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).
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.
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.
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.
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 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.
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 :/
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?
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_s7CsQ5COFSPdlJdygz7TKvU* 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.
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.
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
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.
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.
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.
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. :\
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 :-)
[0] https://matrix.to/#/#activitypub-community:codelutin.com
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.
Man I can't see where the trope of developers implying it's the user's fault is coming from
i’m trying to help fix your problem. can you point me at details so I can investigate?
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.
If you think volunteer dev is so easy then get stuck in and be the change you want to see.
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).
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.
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? :)
Are they contributing code? Money (explicitly to a single specific entity, especially) is hardly the only way to support something.
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.
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.
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.
Every accusation is a confession—you are the troll.
If you are insulted then that is on you.
Name these paid professionals.
Every time I use anything, from MS Teams to Whatsapp, I find myself wishing they were more like Signal.
- 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.
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)?
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
"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"
Turns out that maybe it was for good reasons.
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.
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.
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.
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.
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.
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.
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.
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).
Is Ycombinator (or one of the intermediary investment funds) invested in New Vector?