Summaries, and my counter-arguments as someone who just replaced XMPP with Matrix, and attempting contributions to Matrix code:
> [1] EVOLUTION AND NATURAL SELECTION: https://en.wikipedia.org/wiki/Lindy_effect and a biology analogy taken a bit too far. Extensibility and modularity are important. Extensibility allows adding features, and modularity allows removing features.
The last part sounds reasonable. The first part misses that nature is constantly creating new variations that try to become dominant. The Lindy effect suggests that older things stick around. But in nature, they don't stick around for the sake of age. They stick around because nothing better has out-competed them yet. This analogy seems moot to me.
> [2] IGNORANCE: 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.
Yes, but this is a very shallow argument. The rest of the world has advanced in terms of protocol infrastructure. We're on HTTP/2, and playing with HTTP/3 [1]. IPv6 might actually happen in my lifetime. Meanwhile, XMPP is one-long-XML-document-over-TCP and requires custom tooling for everything. IM protocols don't existing in a vacuum, and should be re-evaluated based on global knowledge, not just IM protocol history.
> [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. If an activist collective doesn't want to store any messages on server for privacy purposes, it can be done by dropping the XEP responsible for archiving. Matrix cannot do this.
However, Matrix is essentially an append-only event store, so in this particular example, yes, you wouldn't be able to disable storing. It's fundamental to Matrix. You can of course prune historical events, but that's not the intent. I feel the bigger question "should an IM protocol be based on distributed state replication?" deserves a better argument than "it's not implemented as an extension." It provides other benefits, like read markers and complete ordering of e.g. ACL changes in rooms.
---
This seems to be many words, but not much insight into the concrete merits of either of XMPP or Matrix.
[1] I'll leave chat protocols on the block chains out of this.
> [1] EVOLUTION AND NATURAL SELECTION: https://en.wikipedia.org/wiki/Lindy_effect and a biology analogy taken a bit too far. Extensibility and modularity are important. Extensibility allows adding features, and modularity allows removing features.
The last part sounds reasonable. The first part misses that nature is constantly creating new variations that try to become dominant. The Lindy effect suggests that older things stick around. But in nature, they don't stick around for the sake of age. They stick around because nothing better has out-competed them yet. This analogy seems moot to me.
> [2] IGNORANCE: 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.
Yes, but this is a very shallow argument. The rest of the world has advanced in terms of protocol infrastructure. We're on HTTP/2, and playing with HTTP/3 [1]. IPv6 might actually happen in my lifetime. Meanwhile, XMPP is one-long-XML-document-over-TCP and requires custom tooling for everything. IM protocols don't existing in a vacuum, and should be re-evaluated based on global knowledge, not just IM protocol history.
> [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. If an activist collective doesn't want to store any messages on server for privacy purposes, it can be done by dropping the XEP responsible for archiving. Matrix cannot do this.
For sure, modularity helps flexibility. Matrix is modular and uses token strings in most places where extensions could occur. https://spec.matrix.org/unstable/client-server-api/#modules
Aside from https://spec.matrix.org/unstable/client-server-api/#send-to-... and https://spec.matrix.org/unstable/client-server-api/#end-to-e... solving this rather strange concern about archiving... The example that you can't drop archiving is silly in the context of flexible deployment. Why does it matter whether archiving is an extension or just a server setting? Someone had to consider the configurability either way.
However, Matrix is essentially an append-only event store, so in this particular example, yes, you wouldn't be able to disable storing. It's fundamental to Matrix. You can of course prune historical events, but that's not the intent. I feel the bigger question "should an IM protocol be based on distributed state replication?" deserves a better argument than "it's not implemented as an extension." It provides other benefits, like read markers and complete ordering of e.g. ACL changes in rooms.
---
This seems to be many words, but not much insight into the concrete merits of either of XMPP or Matrix.
[1] I'll leave chat protocols on the block chains out of this.