[1] EVOLUTION AND NATURAL SELECTION:

I was obsessed with this question for a long-time. Which is the best IM protocol that exists today?

When I asked this to my dear friend, whose work is related to evolutionary biology, he replied "I have no ideas when it comes to computers. But I know this. Anything in this world that has survived for a long-time, had to be fit to withstand selective pressures. So look at what existed for long time, that's probably has properties to adapt well.". Holy hell! Being a biotechnologist, I had to slap myself for not thinking this on my own.

But what makes a protocol fit?
For that I looked at biology first. For a being to evolve, the process happens both forward and backward. That is, the being must pickup (forward) a new feature that will make it fit or drop (backward) a existing feature that is hindering it to be fit. Most importantly, the being must have properties (information in genetic material) that gives it these abilities (pickup or drop features), in the first place.

Now, what properties might that be for protocols?
Extensibility and Modularity. If a protocol is both extensible and modular, it can pickup or drop a feature when needed (Well, protocol is not sentient, developers are the ones who do things). These properties (extensibility and modularity) must be innate nature (design model?) of the protocol, so that it can evolve in response to selective pressures. Here, selective pressures refers to needs of that protocol.

Why both properties and not just any one of them?
As mentioned earlier, evolution is both forward and backward. If a protocol only is extensible, you cannot easily drop a extended feature, if it becomes obsolete, security-critical or bloat. If a protocol is only modular, you cannot easily extend a feature in demand. So a protocol that is both extensible and modular, is fitter than, a protocol that has only one of these properties. In other words, Extensibility and Modularity are evolutionary properties of a protocol.

By design, XMPP has these evolutionary properties, whereas Matrix does not.

[2] IGNORANCE:

Matrix seems to be started because of ignorance. Its stated in its website, under "Imagine a world", the reasons why matrix was started and/or aiming to achieve. Now, there was already XMPP, in which said goals could have been achieved with either existing XEPs or creating new XEPs. Instead, a new protocol was designed from scratch.

I think this kind of trend "Protocol ABC doesn't have this XYZ feature, so let me start a protocol from scratch" should be discouraged. It causes even more fragmentation in IM realm.

This is the very situation where matrix devs should have made use of the properties of XMPP to improve it. Even the outstanding feature (I admit. its a fantastic idea) of matrix, decentralized conversation store, could have been implemented in XMPP as an XEP. Imagine the time and effort spent on improving XMPP, instead of reinventing wheels in matrix. We could have had a neat ubiquitous IM platform.

[3] FLEXIBLE DEPLOYMENT:

IM platforms should be able to be deployed as minimal as possible or as feature as possible. Certain features should be able to be optionally enabled or disabled, based on the needs of the deployer.

For example, if an activist collective decides to provide IM service to its members, but doesn't want to store any messages on server for privacy purposes but to only queue the messages to deliver to clients (like POP instead of IMAP), it can be done by dropping (backward adaptation) the XEP responsible for archiving. Matrix cannot do this.

[4] FINAL THOUGHTS:

Please note that these are criticisms towards Matrix over XMPP, not hate. I appreciate the work done by Matrix devs, especially on decentralized conversation store. It is my current notion that, it will be better for XMPP and Matrix devs to combine their efforts by improving XMPP and bring matrix features to it via XEPs. XEP-Matrix?