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.
> 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.
No, it is not a SPOF. If the PS goes down, traffic keeps flowing as normal; it just doesn’t get spamchecked. They do not give a “go/no go instruction to the larger network”; they are something which servers can check against.
The difference in the distinction is that rooms can pick different PSes to moderate traffic, or choose only to turn them on if they’re under attack, or servers participating in a room can choose to use different ones according to taste, etc.
> No, it is not a SPOF. If the PS goes down, traffic keeps flowing as normal; it just doesn’t get spamchecked. They do not give a “go/no go instruction to the larger network”; they are something which servers can check against.
That is still a failure (to spam check), even if it is not a failure to deliver the messages altogether.
It may also end up being a vulnerability. For example, the attackers might do a some sort of flood attack on the policy server, and then get the abuse through.
> That is still a failure (to spam check), even if it is not a failure to deliver the messages altogether
Yes, but it is not a single point of failure. You can have multiple different policy servers per room, or additional antispam rules per server if you want.
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/