[Arathorn]

This is just not true. There are four main Matrix server implementations today: Synapse, Dendrite, Conduit and Construct. Conduit & Construct are written by entirely independent different parties; all four share zero code; and yet they all can communicate together (modulo beta-ness in some places).

(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 :)

[Andrew_nenakhov]

Both third party implementations have beta status and all entirely independent implementations will be screwed and will stop working each time you decide to significantly change the spec in your monolithic protocil.

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.

[gefhfff]

Matrix is working in a real federated environment between hundreds of servers

[Andrew_nenakhov]

... between server instances provided 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].

I can see zero problems with this decisive approach. /s

[1]: https://news.ycombinator.com/item?id=19421978

[gefhfff]

> between server instances provided by a single dominant vendor

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.

[Andrew_nenakhov]

> Of course, you fall behind if you don't update

In proper federated networks (email, xmpp), you don't.

[gefhfff]

Define proper :D

What I value with Matrix is progress