A roadmap and appeal for help from The Matrix.org Foundation
matrix.org
matrix.org
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.
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.
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 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.
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.
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?
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.
> 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.
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.
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 :)
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.
Hope they can keep going, it is really useful technology.
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.
I don't get it.
I have been burned in the past and I have zero interest in contributing anything that will end up in proprietary code.
> 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...
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.
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.
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.