[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

[Andrew_nenakhov]

What you perceive as progress is just a sign of immaturity of an ecosystem. One player will ALWAYS move faster because he doesn't have to check with other participants, single-handedly self-defining specs and implementing them in own software. But reliance on this model will never allow another participants to enter, and it will always be a one-vendor vehicle.

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.