Re: [Tools-discuss] Trial chat services: matrix and zulip

Matthew Wild <> Mon, 05 October 2020 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93ED73A0FC1 for <>; Mon, 5 Oct 2020 14:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QpxI7QQDjcsU for <>; Mon, 5 Oct 2020 14:50:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E09743A095D for <>; Mon, 5 Oct 2020 14:50:43 -0700 (PDT)
Received: by with SMTP id f142so14166849qke.13 for <>; Mon, 05 Oct 2020 14:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ec7HLDfAKg8cBuEoiPosrBelIj63y9b0NfLNSC1cf98=; b=ANlcRJtEkycAzJXW/W54q7ZOxvrq7i7NNHkdZwcewDtjO9Q+bIzdw6ugjToHdkCS3d 7jeI6fr+/i183GLZNzjgEaFSeDLC+Y4cA3RhIsBauluF7j84201sLJR6CU5Yj82Md2/K YPMweF2Ip3qQPQ9SJwaeqEMoNQGMAeNqqt8JnP4gatBysE1pw5IFiGpJy2LAHkGP4G2k 8nJZuZgRrPKXI1NzPQqXwzVkKu7+l4I5AG92GuUTzbgJD8B7UGaIP8Bwvb00XQcujMiQ 4asz0TYNEJoJ9W4hYsce4NA1O+Rs1i9TPO9VD1neygomzfpSWFc9kjhIqPChsfrPAUoj dIuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ec7HLDfAKg8cBuEoiPosrBelIj63y9b0NfLNSC1cf98=; b=qmnDmAEgT3+Cx/IDaGhNHmbVh2idccGzNCT9fUjgVpfkYrxaq4jAtbYk46x+KKtGKD yX+cUX9awfmi9sERbVQobwbv8p6MX02XkffnbaCLgcFL3Uc63XgusL1DulTdqrpUV3iB Hew0WYymuVMXzMWzgBDRt1+UVI+qTVVwol4Ql0hdrHBT/2ExiTB2oht26cAeXcfCk/Pz aclIspPQ0KXJYE22BybjIJJCDEsNO3A81WTBVvCEouCop2Tg4Vge6u27vlU3spR3JGLS qvls3p5lu9lOqtc231qL8FATyKJLOCfxrvEfrs76ZsRH3ORwRYrez8aTU5QdT/UYSC6i 4jxA==
X-Gm-Message-State: AOAM531ugfYeBjeK4Y8ZmyMaLlMeYXyTVKHidEmAtGHutuIVpIc212JF 0/fcD6/L0x8HE46lGT4rVE6m5ZsFduKOiooEZ5blK8FlqVw=
X-Google-Smtp-Source: ABdhPJwdDyW0xZZtfbjG1xHXaNIByJ9vTd6mfJIJAGAeVrMO7pnmd/Bk6oOrrHiDKgDS6iNGE2IoJjJtQIa4ubtyypw=
X-Received: by 2002:ae9:f701:: with SMTP id s1mr2302931qkg.446.1601934642953; Mon, 05 Oct 2020 14:50:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Matthew Wild <>
Date: Mon, 5 Oct 2020 22:50:31 +0100
Message-ID: <>
To: Tom Pusateri <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Tools-discuss] Trial chat services: matrix and zulip
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Oct 2020 21:50:46 -0000

On Mon, 5 Oct 2020 at 21:23, Tom Pusateri
<> wrote:
> As the Internet standards organization, I think we bear a special responsibility to eat our own dog food. Our job isn’t just to publish a bunch of specs that people may use, but to iterate over solutions that don’t meet the needs of the Internet community and make them better.
> In my opinion, we should not be switching from XMPP to a new chat service without first opening a working group to look into what failed and how to move back to an IETF standards protocol for chat in the future.

I happen to agree that an internet standards organization should aim
to use its own internet standards. That said, I don't think the
dog-fooding principle should take precedence over having functional
communication within the organisation. Luckily in this case that
shouldn't be necessary, as the problems with the current XMPP
deployment can be resolved with minimal effort.

> According to Robert above, it’s a client and server availability problem (not necessarily a protocol problem). Why do vendors not want to support XMPP? Likely because a walled garden is more profitable for them. Is that what the IETF should be encouraging?

There are numerous commercial and non-commercial XMPP projects, both
servers and clients. It's true that the world doesn't run on XMPP in
the way it runs on email, but I don't think the blame for that rests
on the protocol (i.e. the protocol that Google ran at scale for about
10 years, quite possibly their longest-lived communication product
apart from Gmail). You are right that walled gardens are easier and
more profitable in the general case.

Many organisations of all sizes and in all sectors rely heavily on
XMPP, even if it's not necessarily considered trendy and newsworthy at
this point.

> If the XMPP protocol is not sufficient (I understand Matrix is quite well designed), then the IETF should be standardizing something better (even if that means standardizing Matrix).

I believe Matrix is a sufficiently different model to XMPP that it
totally deserves to be standardized, though in parallel to XMPP rather
than a successor. The two protocols are very different, although
interoperability within a certain feature set is totally possible (and
I'm happy to see, being worked on).

But on the primary topic... There are numerous things that can be done
to modernize and improve the current IETF XMPP deployment. The
protocol and implementations have evolved much through the decades,
but less so. Small things like allowing account
registration and providing a web client would go a long way to solve
most of the issues I've seen reported.