[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.

[gefhfff]

Having progress (and thus the possibility of falling behind) doesn't say anything about the speed of progress.

> 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