Matrix is a product developed by one entity that can be installed on premise and has an api. Different instances can communicate with each other. Mattermost also has it but we don't call it a protocol.
(And aside from that, Mattermost doesn't have federation; different instances can not communicate with each other. Although we hope they'll implement Matrix eventually :)
I know, you consider xep structure of XMPP to be a problem, 'because it is hard to orient in it', but in fact it is what makes XMPP so durable and capable to work in a real federated environment.
I can see zero problems with this decisive approach. /s
No, any server instances provided by any vendor
> by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1].
Server instance provider is not the same as software provider. Of course, you fall behind if you don't update. Time progresses, so does software.
In proper federated networks (email, xmpp), you don't.
What I value with Matrix is progress
Proper federated networks are ones that are already past this initial phase of fast progress and where participants have learned to work with each other.
> and it will always be a one-vendor vehicle.
You are clearly not speaking of Matrix: e.g. Element, Beeper, Dataport
How no progress ends up, can be observed with email and xmpp
> Proper federated networks are ones that are already past this initial phase of fast progress
That's made up by you. I claim proper federated networks are ones where you can fall behind