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

[Matthew Hodgson <[e-mail]>]

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 #bifrost:matrix.org 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 Matrix.org 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

-- 
Matthew Hodgson
Matrix.org