Are they extensions of core spec?
Also, the client projects cannot keep up and Element has defacto a monopoly and could always do what they want.
Meanwhile, XMPP has RFCs and therefore is an internet standard. Extensions can be created anytime and go to different states when implementations show up and demonstrate interoperability. There are sets of XEPs that should be implemented depending on use-case, such as instant messaging.
See this post as well:
When one vendor controls all parts of a service (e.g., both a client and server), it has the means to create a boxed platform. Controlling both the server and client allows a vendor to update the client and server without worrying about breaking compatibility with other clients/servers in the larger network. It could update the client to point users to a server that uses a completely different, closed protocol. This is what happened to many XMPP users in the early 2000s.
Problems may arise when development of the spec and production-grade reference implementation grow tightly coupled, leaving third-party implementation feasibility out of the decision-making process.
Case study: Matrix and Element
The only client that implements all the necessary features is Element. In addition to being the most popular client, Element practically serves as the reference client implementation: it’s developed by the same company that builds the dominant servers and most of the spec. The tight coupling between Element and the Matrix spec allow it to add features at a rate too fast for other clients too keep up; pretty much every Matrix user has to open up Element at some point to perform an action that isn’t supported in any other client. On the server side, Synapse is the only server that implements enough of the spec to be usable, with Dendrite coming in second. Both are made by the same company that develops Element.
As a user, consider using clients and servers made by different groups of people to make platform boxing more difficult. Pick implementations that suffer from less feature creep beyond spec compliance. What distinguishes a client shouldn’t be what features it has, but how it implements its features. Obviously, having some unique features is great; problems arise when the number of unique features crosses a certain threshold. Following both these practices encourages implementations to stick to standards compliance, reliability, and compatibility rather than “innovation”. Choose boring technology over shiny new features.
Try venturing outside the mainstream by taking a look at a less popular provider or client. All implementations start somewhere, and a diversity of implementations prevents a rule by oligopoly.
Protocols ensure interoperability between implementations, platforms are not necessary. XMPP works just fine without it.
No, there are many implementations that in fact do not support E2EE and also many that cannot keep up with the many protocol changes.
I partly agree. Email has issues, but largely works. Proprietary “social” media is just hell. I haven’t looked into Nostr yet, but am going to. Matrix is slow, XMPP has proven to work well for a while, it has been around since 1999 after all. It is extensible, which means you can make it work just as well in the future.
Not a fan of Matrix in particular, but I guess it’s still better than Facebook, but that’s not a high bar.