The strategy on Element has been to try to get sustainable by selling secure comms systems for governments - https://element.io/sectors, simply because govts have always been the main folks willing to fund Matrix dev (starting with France back in 2019, then Germany, then US, then UK, then Sweden etc).
Over the last few years we’ve really had to double down on this rather than relying on VC funding.
In terms of competing with Discord, the good news is that in govtech, we’re basically competing against consumer products like Signal and WhatsApp, as well as stuff like Teams. As a result, Element is not that far from a Discord competitor.
On the other hand, right now we are heads down building out stuff like https://element.io/server-suite and adding antivirus to Element Pro, and similar stuff which govts are willing to pay for, in order to keep the lights on. Meanwhile, fun features like custom emoji and discord-style voice rooms are stuck.
The plan is that when we get to break-even we can get back to our mission to provide secure decentralised comms for everyone, not just govts, but right now the focus is purely on being financially sustainable.
That says, if anyone reading this wants to fund us to get back on the broader mission sooner, do let me know!
https://matrix.org/support/ is how to support the Foundation, which uses the $ to keep the protocol independent and on track, and lets Matrix developers like Element spend more time building implementations.
To me it looks like technical scalability issues are a nasty growth-limiting factor for Matrix. When user base grows, the protocol and the implementations hit a some sort of limit above which they don't work properly anymore. Then they hack together a some sort of "solution" to make it to be able to grow a little more, then rinse and repeat.
They store all the messages in a some sort of distributed append-only graph database, which theoretically makes it a bit more fault-tolerant and censorship-resistant, but which does not work very well in real-world use cases. In addition to performance issues, it makes it very hard to filter out all sorts of abuse on public channels before it reaches the clients. In a rather bizarre turn of events, they implemented a kludge solution (1) in which all the messages are routed through a central server, and after then, passed on to the distributed database.
Matrix’s DAG replication scales pretty well - eg rooms like matrix HQ with 65K users spread over 10K+ servers.
Policy Servers are not a kludge, and they do not work by “routing all messages through a central server, and after then, passed onto the distributed database”. They are the opposite, as the linked blog post tries to spell out.
DAG distribution works as normal; messages flow full mesh between servers as always without centralisation. The optional policy server simply provides a /check endpoint which the servers in a given room can use to filter messages for abuse before they pass them to clients. That’s it.
> Matrix’s DAG replication scales pretty well - eg rooms like matrix HQ with 65K users spread over 10K+ servers.
The Matrix HQ room may work every now and then, but it certainly doesn't work well at all.
> Policy Servers are not a kludge, and they do not work by “routing all messages through a central server, and after then, passed onto the distributed database”. They are the opposite, as the linked blog post tries to spell out.
> DAG distribution works as normal; messages flow full mesh between servers as always without centralisation. The optional policy server simply provides a /check endpoint which the servers in a given room can use to filter messages for abuse before they pass them to clients. That’s it.
Distinction without difference. In any case, the single-point-of-failure server is needed to process all the messages and give the go/no go instruction to the larger network.
Policy Servers are not all that optional, since without them, the public rooms will be full of CSAM/gore material, and that is completely unacceptable.
What's changed in the last few years? The only thing I've noticed is the constant nudging to upgrade so I can use custom emojis from different servers.
Praying FOSS can step up, if Matrix/Element plays their cards right, this could be huge for them
The strategy on Element has been to try to get sustainable by selling secure comms systems for governments - https://element.io/sectors, simply because govts have always been the main folks willing to fund Matrix dev (starting with France back in 2019, then Germany, then US, then UK, then Sweden etc).
Over the last few years we’ve really had to double down on this rather than relying on VC funding.
In terms of competing with Discord, the good news is that in govtech, we’re basically competing against consumer products like Signal and WhatsApp, as well as stuff like Teams. As a result, Element is not that far from a Discord competitor.
On the other hand, right now we are heads down building out stuff like https://element.io/server-suite and adding antivirus to Element Pro, and similar stuff which govts are willing to pay for, in order to keep the lights on. Meanwhile, fun features like custom emoji and discord-style voice rooms are stuck.
The plan is that when we get to break-even we can get back to our mission to provide secure decentralised comms for everyone, not just govts, but right now the focus is purely on being financially sustainable.
That says, if anyone reading this wants to fund us to get back on the broader mission sooner, do let me know!
How can individual users fund Matrix development?
https://matrix.org/support/ is how to support the Foundation, which uses the $ to keep the protocol independent and on track, and lets Matrix developers like Element spend more time building implementations.
To me it looks like technical scalability issues are a nasty growth-limiting factor for Matrix. When user base grows, the protocol and the implementations hit a some sort of limit above which they don't work properly anymore. Then they hack together a some sort of "solution" to make it to be able to grow a little more, then rinse and repeat.
They store all the messages in a some sort of distributed append-only graph database, which theoretically makes it a bit more fault-tolerant and censorship-resistant, but which does not work very well in real-world use cases. In addition to performance issues, it makes it very hard to filter out all sorts of abuse on public channels before it reaches the clients. In a rather bizarre turn of events, they implemented a kludge solution (1) in which all the messages are routed through a central server, and after then, passed on to the distributed database.
1) https://matrix.org/blog/2025/04/introducing-policy-servers/
Almost everything you’ve said here is false.
Matrix’s DAG replication scales pretty well - eg rooms like matrix HQ with 65K users spread over 10K+ servers.
Policy Servers are not a kludge, and they do not work by “routing all messages through a central server, and after then, passed onto the distributed database”. They are the opposite, as the linked blog post tries to spell out.
DAG distribution works as normal; messages flow full mesh between servers as always without centralisation. The optional policy server simply provides a /check endpoint which the servers in a given room can use to filter messages for abuse before they pass them to clients. That’s it.
> Matrix’s DAG replication scales pretty well - eg rooms like matrix HQ with 65K users spread over 10K+ servers.
The Matrix HQ room may work every now and then, but it certainly doesn't work well at all.
> Policy Servers are not a kludge, and they do not work by “routing all messages through a central server, and after then, passed onto the distributed database”. They are the opposite, as the linked blog post tries to spell out.
> DAG distribution works as normal; messages flow full mesh between servers as always without centralisation. The optional policy server simply provides a /check endpoint which the servers in a given room can use to filter messages for abuse before they pass them to clients. That’s it.
Distinction without difference. In any case, the single-point-of-failure server is needed to process all the messages and give the go/no go instruction to the larger network.
Policy Servers are not all that optional, since without them, the public rooms will be full of CSAM/gore material, and that is completely unacceptable.
We've seen a pretty decent influx at Revolt.
https://zulip.com/ is good but videoconferencing has to be a 3d party
Well, let the enshittification begin. If we don't like it, we can spin up OSS alternatives.
Discord is already pretty terrible now compared to a couple years ago.
But Blizzard Activision style management is a sure fire way to make me leave.
What's changed in the last few years? The only thing I've noticed is the constant nudging to upgrade so I can use custom emojis from different servers.