actually, come to think of it, an excellent way for Microsoft to fend off this anti-competition accusation would be to go embrace Matrix for use in Teams and demonstrate they support data portability, and are serious about not locking users in.
On the Matrix side we'd be happy to help them do so (we have a few big undisclosed projects already on the go to expose existing chat systems natively into Matrix :)
This is the "new" Microsoft. Just like the old Microsoft. The other two Es will follow just as soon as the optics permit.
eta: (Sorry to sound old and curmudgeonly, but... I am old and curmudgeonly. I do not believe for one little instant that any corporate culture is capable of reversing its lifelong ingrained habits and postures.)
XMPP and ActivityPub are the other obvious federated communication protocols (albeit with very different emphases; XMPP being message-passing at its core; ActivityPub being subscribing to activity streams at its core; Matrix being history-replication at its core).
Where Matrix needs competition most is in homeserver implementations. There are partial Go, C++/RockDB(?!), Rust, Elixir, and Java projects, but none full-featured.
It's nice that the full-featured Python one can use Postgres, and succeed at operating Matrix.org, but it's not nice that you have to frequently "restart its synchrotrons" for users to be able to adjust their notification preferences. Python is a capable language for smaller systems, but at >120K lines, it worries me.
It also worries me that there is no way to split traffic to an overloaded system out to two not-overloaded systems. Is that fundamental to the architecture? That seems like the top priority to fix. Can it be done without breaking the five other server implementation projects too badly?
There's a lot of stale/wrong info here. I'd say that we have pretty healthy competition in homeserver implementation these days. The four options currently in active development are Synapse (Python), Dendrite (Go), Conduit (Rust) and Construct (C++).
In terms of Synapse (https://github.com/matrix-org/synapse): originally the initial prototype for Matrix, historically it had performance and architectural issues given we were frantically implementing features to prove Matrix rather focusing on perf. Since hitting 1.0 a year ago though things have improved massively. Almost all of Synapse scales horizontally; we've switched to Python 3 and have almost finished switching to asyncio (improving perf and maintenance massively); and lots of schema perf issues have been shaken out. Unsure what you're thinking about w.r.t. "restart its synchrotrons", but that just sounds like a bug that got shaken out years ago.
Dendrite (https://github.com/matrix-org/dendrite), meanwhile, is in very active dev by the core Matrix team - there was a long hiatus while we had to focus exclusively on Synapse, but since the beginning of this year there are folks working fulltime on it, and it's looking super promising as a very microservices-driven model, with each service scaling arbitrarily horizontally, connected via append-only logs. All the P2P Matrix work is built on it (running it clientside, as it's such small footprint). It's effectively in competition with Synapse, and worked on by different teams. It federates today and can be run as late alpha, but the CS API is missing some features that we're currently adding.
Conduit (https://conduit.rs) is the new kid on the block, written by the community in Rust, using a strictly monolithic structure for now, using Sled as a key value store for storage. It's incredibly fast, and has impressively good CS API coverage (including E2EE, whereas Dendrite's E2EE support is only landing this week), but federation work hasn't begun yet (which is a bit worrying, as you need to design/build with federation in mind from square 1). It has a great community though, and is entirely independent of the core Matrix team, and you could say it's in competition with Dendrite.
Construct (https://github.com/matrix-construct/construct) is a C++ server using rocksdb for storage. It's a community project entirely independent of the core Matrix team; it federates, and has extensive CS API coverage, but unfortunately the project's author has been incredibly antagonistic to the core Matrix team over the years, which makes it rather hard for us to comment further.
TL;DR: Matrix homeserver dev is in a good place right now :)
I was going on public information, such as the FAQ about Synapse, which explained in detail how matrix.org could not shard out their Synapse server; it is good that the FAQ is now completely wrong on that. I will need to ask over at Construct about the nature of their disagreement with the core team.
I had asked at Element why it would not update notification preferences, and they said my homeserver probably needed its synchrotrons restarted. Does this mean the version of Synapse they run is badly outdated?
