Subject: [Tools-discuss] Matrix-XMPP bridge

From: "Martin Thomson" <[email-masked]>
Date: Fri, 23 Oct 2020 11:48:21 +1100

For what it is worth, prior to discovering the XMPP trial server, I was using the bridge from Matrix to join working group sessions.  This worked quite well and I appreciated having it, even if the UX was rocky.

I've just tried out the XMPP web UI and it is a vast improvement over running my own client.  This too has some rough edges (try joining "<wg>@jabber.ietf.org" rather than just "<wg>").  One concern I have with XMPP is that the presence aspects of XMPP are somewhere between an anti-feature and a relic of a bygone era.

Overall, the only real problem that I have is with the trials is that there are three of them.  I don't yet have any data to let me say which is objectively "better".

---

From: Matthew Wild <[email-masked]>
Date: Fri, 23 Oct 2020 12:20:48 +0100

Hi Martin,

On Fri, 23 Oct 2020 at 01:49, Martin Thomson <[email-masked]> wrote:
> I've just tried out the XMPP web UI and it is a vast improvement over running my own client.  This too has some rough edges (try joining "<wg>@jabber.ietf.org" rather than just "<wg>").

Glad you found the web client easier! The primary recurring feedback
from IETF 107 regarding XMPP was that some people struggled or were
unable (e.g. due to company policy or corporate firewalls) to install
software locally. The web client was therefore an essential step
towards improving the XMPP setup.

Thanks for the report about the issue joining when providing a full
room address. This is a quirk of the configuration mode that the web
client is in (it is "locked" to groups on jabber.ietf.org, and in this
mode silently expects only a room name to be entered). I have filed an
issue report here to get this fixed:
https://github.com/conversejs/converse.js/issues/2311

> One concern I have with XMPP is that the presence aspects of XMPP are somewhere between an anti-feature and a relic of a bygone era.

You're right that presence is a secondary feature these days for many
purposes - many people have multiple devices, and at least one of them
is semi-permanently connected to the internet. However XMPP has
evolved with this change, most modern clients are hiding or
de-emphasizing presence information in their UI. Instead they are
opting to show membership information when this is more permanent
(e.g. in private groups). That is, it's primarily a UX consideration
for clients to adapt to at this point. At the protocol level we
generally still track who is currently connected, which is useful for
some things, and fine for all but the largest of rooms (and it can be
disabled for those).

We also have a newer group chat protocol (MIX) that is gradually being
implemented by clients and servers which formally moves presence to a
second-class feature of groups.

Matrix groups are based on more permanent membership by default, and
although it does support presence it is often disabled on larger
deployments (for performance reasons, as I understand it). This
approach has different tradeoffs, e.g. due to this many rooms on the
Matrix network only grow in size and have many more members than they
have active users. I believe a bot is used (or planned?) to clean up
membership of inactive users after a configurable period (see
https://github.com/turt2live/matrix-wishlist/issues/82 ).

In summary, as many of us here will know, protocol design is hard and
full of tradeoffs. And that's before we get to UX and the moving
target that is "user expectations" :)

Thanks again for the helpful feedback about your experience!

Regards,
Matthew