I believe Matrix's Now-or-Never Moment has passed.
My last attempt to use Matrox with a group ended in:
- 3 users not receiving notifications on Android
- 2 users regularly not being able to decrypt messages
- No one being able to invite new contacts unless on Desktop
At the same time, Element was working on probably the third app redesign, when the current one... was fine.
These issues crop up, without fail, every time I try to set someone up with Matrix. If
If after so many years they still haven't ironed out the basics, they never will.
I agree (as project lead for Matrix) that we've ended up going much slower than I'd have hoped. The sibling probably has it right that we bit off more than we could chew. However, we've kept doggedly chewing, and after hitting 1.0 back in 2020 we're now gearing up to 2.0 which brings both performance & stability to mainstream levels.
The problems you've described on (presumably) Element Android are precisely why Element just rebuilt the app (as Element X) on a rust SDK which solves encryption & push problems in one place, rather than being split chasing bugs in triplicate across iOS, Android and Web/Desktop. In turn, this explains why the old apps have stalled.
Ive been using matrix private instance for group of nontechnical users for almost a decade now. First with Synapse and now Conduit.
Imho its OK. There are issues with e2ee and well it took most of that decade for Synapse 1.0 stable release…
But if you want private Slack/Discord alternative and run your instance Matrix is still your best choice. Running Conduit with sqlite is pretty easy it. Conduit doesnt yet have all the features but i hope its gonna get there. Element and other clients are pretty good. I am not sure there is better alternative that has threads, image uploads, markdown… all the little stuff people nowdays expect.
Notifications have gotten better, especially if you use FluffyChat. No clue about the decryption errors.
I find two things way more annoying just because they're so basic. Number one being the fact that replies still look visually wonky quite often and the fact that they're fully RED. Why would they ever use the danger colour for normal things?! The second problem is that when you make a new session it doesn't trust old messages and displays an icon that's utterly useless.
The last one is especially annoying considering how often the clients just corrupt their state and need logging in again. Things like Keybase (RIP) got these things right from the start.
Almost feels like they bit off more than they could chew with some features. The end to end encryption of group chats is pretty revolutionary, but it's never really felt like it worked, and none of the competitors even try as far as I know. It's just too hard. Being federated probably makes every feature 10x harder to implement.
The bridging feature that they sell also never really worked properly for me. It would go down almost weekly, messages would go missing, get delayed, get reordered, etc. I never felt confident using it and would have to check the actual app to see it come through as expected.
I had to choose a groupchat option for an event I run and the choice ended up being XMPP because the Matrix mobile apps we tried were all crashy. I wish everyone working on Matrix the very best, and will continue to run a demo for myself once a year.
Thanks for continuing to give Matrix a try! There are rough edges, for sure. I'm excited to hear what you think the next time you give it a spin – your experience is valuable feedback for us.
Bit of a tangent (though it is directly mentioned in TFA), does anyone knows why Signal spends 1.3M/yr on data storage?
I understand that it's probably the result of a massive amount of requests/transactions done with a cloud provider, and the actual storage needs are probably pretty low given the ephemeral nature of their system.
But at what point does it become financially irresponsible to not run baremetal?
> When you send a message, the Signal service temporarily queues that message for delivery. As soon as your message is delivered, that small bundle of encrypted data (i.e. your message) can be dropped from the queue. The storage of end-to-end encrypted files is temporary too, and any undelivered end-to-end encrypted data is automatically purged after a period of inactivity. Even though everything is only temporary, this storage still costs Signal around $1.3 million dollars per year.
I assume they're probably speaking honestly, and have no reason to investigate (since I don't use it). But if you were doing a critical analysis, I guess you could consider that, for $1.3M/year, one could also store a lot of "metadata" for later traffic analysis, social network mapping, propagation tracking, etc. It'd be tickling to think that fact could be hiding in plain sight the whole time, in invoices and accounting disclosures.
> But at what point does it become financially irresponsible to not run baremetal?
At the point where hosting is part of your value proposition, to the point that you can do significantly better than commodity managed hosting (either because there is something about your use case that allows vertically integrated hosting to outperform, or you're becoming a hosting company). 1.3M of off-the-shelf hosting sounds a fair way short of that to me.
I like matrix as much as anyone else around here, and I would like to see it survive and prosper. That being said, if over 60% of the annual “expenses” of your nonprofit goes to “management” covering the salaries of four people who have other full time jobs, you really need to do a better job at managing finances.
Despite having been fairly critical of the Foundation elsewhere in this thread, I have to point out that this comment is wrong.
Josh is full-time employed by the Foundation, without another job.
It does seem pretty odd that they presented their expenses being just two million short of the PSF's expenses as useful for "putting things in perspective," given how much larger in scope the PSF is, especially after the cuts the Foundation made last year, however.
Thanks for your enthusiasm for Matrix! We're at a critical point in its evolution, but there's a lot of reason to be hopeful and excited about the future – and we'll be digging deeper into that in each of the following blog posts in the series.
I think the others have covered it pretty well, but just so you hear it from the source:
> if over 60% of the annual “expenses” of your nonprofit goes to “management” covering the salaries of four people who have other full time jobs,
That is an incorrect reading of the situation. The four full-timers who work for the Foundation do not have other jobs, so we are covering 100% of their salary. And that line item on the budget _also_ covers a bunch of part-timers, such as the SREs who keep the Matrix.org homeserver running.
If you have any other questions or concerns, I'm more than happy to speak to them :)
as the sibling says, this comment is just plain wrong. the four people funded by the foundation (MD, T&S, standards & advocacy) have no other source of salary than foundation donations.
They open-cored Synapse. I guess Element needs money, so they're crowdfunding. It doesn't take long to see that the open protocol is pretty geared towards Synapse/Element. By the way this is out of date: https://matrix.org/ecosystem/servers/ It says Apache 2, but if you click it, it goes to an archived repository, and if you click the link in the README to the new repository, it's under AGPL. That would be community-driven and all if they wanted to use it, but it's another case of AGPL for thee, but not for me.
Element != the Matrix.org Foundation. Element relicensed Synapse. The Foundation is running a fundraiser.
I'm a little confused about your comment "AGPL for me, but not for thee." Can you unpack that a bit? Synapse is available under an AGPL license for _everyone_.
Thanks for flagging the error on our website, I believe there's a PR currently in flight to fix that.
Yes, I know, it's how this attempt to solicit donations works.
> I'm a little confused about your comment "AGPL for me, but not for thee." Can you unpack that a bit? Synapse is available under an AGPL license for _everyone_.
It's that Element wouldn't want to be able to use it under only the AGPL. That would be a nightmare. So it is for people who were interested in participating in the Matrix.org ecosystem because it purported to be vendor neutral. Now it is quite clearly no longer vendor neutral. There is no longer a server listed as stable that is available under a license that is acceptable to the owners of the repo as the sole license under which the owner may use it.
I'm drawing the equivalence of open-core Synapse to open-core Matrix. I think this is reasonable, based on the position of Synapse in Matrix ecosystem. I get what you're saying, I just don't happen to see it that way, as someone who has watched Matrix/Element over the last few years. Feel free to show me evidence of decoupling that I may have missed.
> Otherwise, we need to start scaling back programs and staff starting January 2025.
They've already done so. 2023 saw a (rather extensive) wave of layoffs, and a reduction in scale.
Part of the issue is that Matthew is not the best communicator, which isn't great for fundraising. That being said, Josh isn't off to a strong start, either.
Somehow, neither of them managed to spin the Apache -> AGPL move for Synapse as a good thing, despite it pretty transparently being better not only for the ecosystem, but for users. No freedom is lost from the perspective of a user of the software with the switch, as Apache isn't copyleft.
The CLA is unfortunate, and a less controversial strategy would have been to emulate Trolltech's "If we become a bad actor, we're legally compelled to release the source under a permissive license" approach to CLAs.
Further, the wording of docs around the CLA is really scummy, even if unintentional.
> Everyone is welcome to contribute code to Synapse, provided that they are willing to license their contributions to Element under a Contributor License Agreement (CLA). This ensures that their contribution will be made available under an OSI-approved open-source license, currently Affero General Public License v3 (AGPLv3).
It's hard to see this as short of deliberately misleading. For developer trust, they should have just said transparently in the paragraph that they needed it to sell AGPL exceptions. The wording of the CLA itself is pretty bad, though I'm sure the lawyer responsible thought it was clever.
> Element shall be entitled to make Your Contribution available under Element’s proprietary software licence, provided that Element shall also make Your Contribution available under the terms of an OSI-approved open-source license.
This offers no protection against Element dropping open source entirely the next time they hit a "budget crisis." Your Contribution will be safe in the archived version, but there's not even a guarantee that your attribution will be kept with the OSI license they choose to relicense your commit to upon subsequent releases, and this will still be within the legal rights of Element. The only thing you need to do to fulfill availability requirements for the Simplified BSD License is to put the copyright notice in the binary.
Regardless of the technical merits of the platform, or lack thereof, the consistent failures in communication constantly make it feel like things are going to implode, and it seems like every time an adjustment for sustainability needs to happen, the Foundation drives itself directly into a ditch in terms of communication and outcomes. Even assuming good faith, which is fair, given the middle-upper class salaries of the Foundation members, they consistently choose to take the options that look like they're acting in the worst faith, both from a comms standpoint and an outcomes standpoint.
Conversely I have submitted patches to proprietary, non-OSI-approved-license projects because it is productive for me. If I was not getting paid, sure, but you can have proprietary code and accept community contribution, but you need a CLA.
> This offers no protection against Element dropping open source entirely the next time they hit a "budget crisis."
IANAL, but I think you have this completely wrong. The clarification to the Apache CLA was added to ensure that if Element ever distributed contributed code as proprietary (i.e. by providing an AGPL exception to someone allergic to AGPL) then we will also have to distribute that code as FOSS. It is *LITERALLY* stopping us from dropping open source.
> the consistent failures in communication constantly make it feel like things are going to implode
I wonder how much of the "consistent failures in communication" are due to FUD, and how much is due to bad comms in the first place...
> I wonder how much of the "consistent failures in communication" are due to FUD, and how much is due to bad comms in the first place...
As someone who doesn't read outside perspectives on Matrix, but probably checks the Foundation blog once a month, I would say the latter. You've created a perfectly tolerable product, aside from some (admittedly unfortunate) edge cases. More or less everyone acknowledges that Matrix is, at the bare minimum, usable for individuals chatting, if not the best option right now.
Hey, thanks for sharing your concerns. I think we need to start right at square 0: Element is not the same as the Matrix.org Foundation, and the Foundation has not had layoffs or a reduction in scale.
We did EOL the public Libera.Chat<->Matrix bridge we were previously operating, while at the same time expanding our advocacy work to make sure we don't end up with legislators undermining their goals around safety by introducing backdoors or dangerous surveillance.
I'd _love_ to hear your questions and concerns, so that I can address them, but it is hard to address what you've currently written as it is all based on the premise that Element and the Foundation are one in the same.
It isn't written under the premise that Element and the Foundation are the same.
Rather, it's written under the premise that, at the time, there wasn't enough distinction between "The Matrix.org Foundation" and Element for it to make sense to differentiate the two as far as layoffs are concerned prior to hiring you: The Element layoff saw the firing of Matrix core contributors, and the Foundation had no employees at that time (as far as I'm aware).
The Element layoffs saw the reduction of the entirety of people concerned with Trust & Safety for Matrix. There is now one person hired by Matrix.org to handle it. This implies continuity.
The rest of the concerns listed are primarily about Element; I'm pretty confident the Foundation will end up doing okay in the long run. It is concerning that the reference implementation of the Matrix spec isn't owned by the Foundation and has a CLA, but I don't think there's a way of alleviating that concern in the present day with present funding levels, aside from Element assigning copyright of Dendrite to Matrix.org, or something.
My last attempt to use Matrox with a group ended in:
- 3 users not receiving notifications on Android
- 2 users regularly not being able to decrypt messages
- No one being able to invite new contacts unless on Desktop
At the same time, Element was working on probably the third app redesign, when the current one... was fine.
These issues crop up, without fail, every time I try to set someone up with Matrix. If If after so many years they still haven't ironed out the basics, they never will.