I said most of the same things in the Matrix foundation's server. The general response from the team was: "Pay money or shut up and accept what we give you". 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. There's two clients. One that's fast, and one that's full featured. You can either skip out on features, or use something slow.
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.
"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.)
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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).
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.
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
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.
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.
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?
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)
Huge 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.
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!
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.
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
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).
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).
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. :\
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.
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
- 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.
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.
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 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
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.
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).
"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"
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
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.
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 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.
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).
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? :)
> 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.
> 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.
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.
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).
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.
> According to Google reCAPTCHA, Hcaptcha and Cloudflare Turnstile, I’m a robot. Although I haven’t seen an engraved plate with the label T-800 on myself yet, these days I might as well just be a rogue LLM. Does it even matter anymore?
I said most of the same things in the Matrix foundation's server. The general response from the team was: "Pay money or shut up and accept what we give you". 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. There's two clients. One that's fast, and one that's full featured. You can either skip out on features, or use something slow.
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...
> 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".
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 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?
> 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?
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.
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.
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.
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 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 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.
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.
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.
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.
This implies developers care about performance.
Element X's performance is great, and the app was built both by product, design & developers (with the performance focus led by dev).
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.
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'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.
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.
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.
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 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.
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 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).
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.
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.
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
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.
> 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.
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 :/
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?
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)
Huge 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.
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.
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
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).
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
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. :\
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/
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.
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
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.
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 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
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.
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.
Signal's desktop app is slower to load and has less features than Element Desktop, despite both using the same stack of Electron and Sqlite.
Worst in terms of user freedom as well. Because according to moxie, everyone is incompetent to host their own. He was wrong
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
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"
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.
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
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.
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 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.
It's gaining traction. Matrix will prevail, sooner or later. Don't give up on it just yet
The year of the Matrix desktop?
So what are the best alternatives?
Xmpp! Was and is
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?
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).
from jabber/xmpp and back. time is a flat circle
Why not just use jabber and omemo?
I'm guessing because he doesn't just want to talk with himself
"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.
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? :)
> 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.
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.
Would be interested to hear about alternatives.
Are you deliberately using QR only for your contact details?
the amount of spec change proposals over the years is wild: https://0x0.st/H8h-.png
Remember that their main criticism of XMPP was there is just too many protocols extensions and proposals!
Turns out that maybe it was for good reasons.
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.
this is a good thing, right? spec change proposals is how the spec evolves - they literally turn into PRs to the spec.
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.
Every time it was suggested to adopt matrix into our platform, we took one look at the protocol docs and said NOPE.
What bit of the protocol docs made you nope out?
[flagged]
From https://xn--gckvb8fzb.com/faq/:
> According to Google reCAPTCHA, Hcaptcha and Cloudflare Turnstile, I’m a robot. Although I haven’t seen an engraved plate with the label T-800 on myself yet, these days I might as well just be a rogue LLM. Does it even matter anymore?
:)
to be clear, they can be content with it themselves -- i'm self-filtering and think it's important to do so visibly and attributively c: