[Tools-discuss] Why IETF should keep XMPP as IM standard, instead of Matrix?
Raghav Gururajan <firstname.lastname@example.org> Thu, 08 April 2021 23:11 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25A63A20EC for <email@example.com>; Thu, 8 Apr 2021 16:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([220.127.116.11]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDHuCT2NTQVF for <firstname.lastname@example.org>; Thu, 8 Apr 2021 16:11:32 -0700 (PDT)
Received: from out1.migadu.com (out1.migadu.com [18.104.22.168]) (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 <email@example.com>; Thu, 8 Apr 2021 16:11:32 -0700 (PDT)
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 firstname.lastname@example.org and include these headers.
From: Raghav Gururajan <email@example.com>
Date: Thu, 8 Apr 2021 19:11:23 -0400
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S93DONn5Jgsh4LSp0lmO7ZYF7pMHnoZ8o"
Subject: [Tools-discuss] Why IETF should keep XMPP as IM standard, instead of Matrix?
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:email@example.com?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.  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.  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.  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.  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? I request IETF to consider my above thoughts, while evaluating standards for IM, as it is a matter of Internet's health. Regards, Raghav "RG" Gururajan.
- [Tools-discuss] Why IETF should keep XMPP as IM s… Raghav Gururajan