[Tools-discuss] Why IETF should keep XMPP as IM standard, instead of Matrix?

Raghav Gururajan <rg@raghavgururajan.name> Thu, 08 April 2021 23:11 UTC

Return-Path: <rg@raghavgururajan.name>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E25A63A20EC for <tools-discuss@ietfa.amsl.com>; Thu, 8 Apr 2021 16:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raghavgururajan.name
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yDHuCT2NTQVF for <tools-discuss@ietfa.amsl.com>; Thu, 8 Apr 2021 16:11:32 -0700 (PDT)
Received: from out1.migadu.com (out1.migadu.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689B73A20E6 for <tools-discuss@ietf.org>; Thu, 8 Apr 2021 16:11:32 -0700 (PDT)
To: tools-discuss@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raghavgururajan.name; s=key1; t=1617923485; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=NaUV/0tqPMlD+mP2TZRHZZSB/AQMJe//KQ2hBw+fp6c=; b=ZJSYN4600L9+0jdgVC23hhWtVOXwe1/pQKORtsPjlIz78qcI+QD4XVu2zaZj2lcAlFScxz XsTvVflyKOn9kFIN1FVbCZNmFdIUjOxaIdtcgPqs0pNvwM7OtZmsdSjDQpTa/0LHrIT4Fx JyFSP4bmdzDGrA9k4i4STw6mOhjuIFqGQscJjHIV6Yq6ivBPhX30xEaGrQKnBMz68ye7QZ aY00RzyHsHZ79qagPTCU3WBHemAUzJxyAngPEUO0Vy6Hn02li/6fnIW3IQD9A3mLfgKVSC Lx3w9riUQKe1LtYzJEmveylzKzDKEXxGQ8jKIhkZPJX7pqIc+/Zip2jT1t7bAw==
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Raghav Gururajan <rg@raghavgururajan.name>
Message-ID: <c5a3a32b-22de-bfbe-d1e4-317b1c1745af@raghavgururajan.name>
Date: Thu, 8 Apr 2021 19:11:23 -0400
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S93DONn5Jgsh4LSp0lmO7ZYF7pMHnoZ8o"
X-Migadu-Flow: FLOW_OUT
X-Migadu-Auth-User: rg@raghavgururajan.name
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/Cj7n-7HwsN8xBzXCjD1pjD1j9Cg>
Subject: [Tools-discuss] Why IETF should keep XMPP as IM standard, instead of Matrix?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 23:11:38 -0000

Hello Folks!

Here are my thoughts on why IETF should keep XMPP as IM standard, 
instead of Matrix.


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.


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.


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.


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?

I request IETF to consider my above thoughts, while evaluating standards 
for IM, as it is a matter of Internet's health.

Raghav "RG" Gururajan.