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

Matthew Hodgson <> Sat, 03 October 2020 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E1403A0141 for <>; Sat, 3 Oct 2020 12:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Status: No, score=-2.311 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, NICE_REPLY_A=-0.213, 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 (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cq0wuox7Rxs3 for <>; Sat, 3 Oct 2020 12:51:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEC273A0140 for <>; Sat, 3 Oct 2020 12:51:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=polemos; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=HPBzc+9L2d7QqhpzVDyvd2UWXTyirAp6CLdiJHjcr0U=; b=I3yBLnZPlVut7aJOwIvGj+o257 MMG7rx4+ufTPJ5egZ/1SASkO3g0/FPi1ppz2H6DMo0Y2/wa4KAGibxbMucLbSakrbvPY103nJOdQS aZIcRksX8TWuw+RGP9s9k5jHwfsW6+2ArYTAUhRMwNmLNwQHvrVmnvLyr0DS/g8v3JSsxLvz3ge3E GHNeq88ozAQxm2sFYW/V3PU2OZdE3dwkdqpA0Ip8tWRANweJjt+izodZCbMqefSp1R+FjwY0YbVCw aXK2rzC2CPyuejxK7Gt7i/x5uydEHInMvqiL6Y9+3GvBdHQhuyJOFQKKz5whlZk8u1of0G12BaG7a k01why+Mq2A/xM2IOrbh/9/V9J+EvV8yBcOopZOmqnDrAFdYytSexsJWqX8RlNOhzNQI9lMft+UP6 znh55akdzMbzE7QNS2aoEr9gRNNHzL+u2v9CqsPWa/vE6cXezOiAPqfwqT2sykBQVzUrUEFBlBdSG fVzCBFjJVVLJpcVc4fMSw6EiHPpmvd6Rc0KWIkCemPc2nWR5MqFTAVlmERT91ra82n/zRFJG2eHPp JKNS7LA6+l+yxweX1bfcDWBf/IJWtSWxuabFcIER8a3KRpkcSdNEBWNJWpwQ8aBasS46u/FpZ1Tt5 NU+ItNkOJH0gXMYgEqQDZHfa1w0UdXk9xgHC01suw=;
Received: from ([] helo=bucephalus.local) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1kOnYs-0008Rw-1x for; Sat, 03 Oct 2020 19:51:18 +0000
References: <> <> <> <>
From: Matthew Hodgson <>
Message-ID: <>
Date: Sat, 3 Oct 2020 20:51:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Thunderbird/82.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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: Sat, 03 Oct 2020 19:51:21 -0000

On 02/10/2020 12:44, Johanna S wrote:

> On 02.10.20 01:43, Matthew Hodgson wrote:
>> On the other hand, XMPP<->Matrix bridging is pretty good
> Not sure if that was meant as a funny joke or if you ever actually tried
> to use that bridge from the XMPP side.

I've used it with Adium and Pidgin on and off and it's worked 
adequately.  There have been some stability bugs recently, but we have 
one high profile user for whom we're currently trying to get it 
production grade (two, if you include IETF).

> It has such severe bugs that it
> is hardly usable with any modern XMPP client. You can't even leave a
> room [1]. I know several server operators that blacklisted the gateway
> because its non-compliance caused problems with clients.

Weird; I can leave MUCs fine with Adium, and it doesn't SPIM me. I'm 
talking to ge0rg on to try to understand that bug 
(it's not exactly helpful that the debug logs have been deleted).

> A good bridge is standard-compliant and gives good UX *on both sides* of
> the bridge, not only on the Matrix side. In my experience, the bot-based
> bridging approach (like Matterbridge) is a better way to do a
> XMPP<->Matrix bridge than the bifrost bridge, when looking from the XMPP
> side - because at least everything works as it should and is
> standard-compliant, even if every message got an ugly prefix.

I would expect that technologies designed specifically for bridging 
(XMPP Components, and the Matrix Application Service API respectively) 
should give infinitely better results than a bodge like Matterbridge... 
assuming the proper bridge isn't buggy, of course.

> I have hard times understanding how Matrix folks praise their XMPP
> bridge while at the same time XMPP people tell you that the bridge is
> working really *really* bad. If was a for-profit company, I'd
> tend to say it's just empty marketing claims to fraud customers.

Clearly I've misunderstood how much XMPP people dislike the bridge.

All I can say is:

  * We have (as of the last week) a high profile user who needs to use 
it in production, which is triggering an overdue wave of maintenance - 
and the possibility of it being useful for IETF gives us even more 
reason to improve it.

  * By deriding the bridge, you're just harming both sides of it. IETF 
is less likely to use Matrix if they believe its XMPP bridge is as 
irredeemably bad as you say; and meanwhile it sounds like pure XMPP is 
off the cards anyway.  So, it just pushes IETF back towards Slack, or 
perhaps Zulip, whose XMPP bridging is unavoidably limited (aiui) due to 
the different threading semantics.  In other words: both XMPP and Matrix 
lose - rather than using the opp here as a catalyst to actually improve 
the bridge, and thus keep XMPP part of the IETF use case.

So, please consider that Matrix and XMPP are on the same side here: the 
enemy is the proprietary vendor-locked silos - not other open 
communication protocols.  We should be working together to improve 
interop and bridging, rather than trying to put each other down.


Matthew Hodgson