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

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Oct 2020 11:18:22 -0400

It might be more effective to trial them sequentially rather than in parallel. 

> On Oct 1, 2020, at 10:33, Robert Sparks <[email-masked]> wrote:
> 
> We are deploying trials of the matrix and zulip chat services to gain
> operational experience and get community feedback about how well these
> services meet the need for IETF related chat.
> 
> We have clear evidence from the IETF 107 post-meeting survey
> (https://www.ietf.org/media/documents/ietf-107-survey-results.pdf) that many
> IETF participants find jabber a significant problem.  This is partly due to
> difficulties in finding a free jabber service and partly due to client issues.
> There are two paths to try to resolve these problems, one is to improve the
> IETF jabber service and the other is to switch to an alternative groupchat
> solution.  The community has already taken a step on the latter path with the
> introduction of an IETF Slack space, and we want to ensure that this path is
> properly explored by widening the range of options to well established
> free/open source tools.
> 
> The installs currently have almost no local configuration or customization.
> Over the next few weeks, we will be exploring reconfiguring them to use
> datatracker credentials for sign-in, and explore bridging between these
> systems, Slack, and Jabber. One consequence of these explorations is that there
> will  likely be times, outside of meetings, when accounts will be disrupted or
> even removed and will have to be recreated. Initially, we suggest you use an
> email address for the username on each service.
> 
> We considered running these trials using instances run by the Zulip or Matrix
> communities. We went with instances operated by the secretariat to learn what
> would be needed if the community felt self-hosting chat was important in the
> long-term.
> 
> The services can be found at matrix-trial1.ietf.org and zulip-trial1.ietf.org.
> 
> Any matrix client can be used with the trial matrix server. There is also
> a web client available at at matrix-trial1.ietf.org.
> 
> Similarly any zulip client can be used with the trial zulip server, which
> has a built in web interface.
> 
> We would like feedback on how well each client meets chat needs during
> meetings, both the full online IETF 109 meeting, iterims, adhocs, and hallway
> conversations.
> 
> Around December, we will assess our experiences and the feedback received to
> inform what chat services we provide in the future and how we will operate
> them. In January, these trial instances will be taken down. We do not intend to
> preserve or migrate any account configuration or chat history from the trial
> instances as we move forward.
> 
> This does add to the potentially confusing large number of places conversation
> might take place. We hope to address that with some level of bridging, at least
> with Jabber, but have been cautioned by the respective development communities
> that bridging between Zulip and Matrix is unsatisfying since the conversation
> models in the two applications are so different.
> 
> The chat services are intended to be explorational and informal. However,
> please treat them as contexts where contribution rules apply (See
> https://www.ietf.org/about/note-well/).
> 
> We are not, at this time, planning to host jabber accounts. We may revisit that
> as an option as we continue to gather more feedback.
> 
> Please send feedback on the services to [email-masked]
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Oct 2020 17:47:58 +0200

On 2020-10-01, at 16:25, Robert Sparks <[email-masked]> wrote:
> matrix-trial1.ietf.org.

OMG what is that riot-bot and why does it have to bother me with loud fake music.
(And I also wouldn’t mind if it didn’t lock up my browser.)

You never get a second chance to make a first impression, but this one is the worst intentionally left impression I have had this decade.  Not relevant for the actual experiment, but still jarring.   On to zulip...

Grüße, Carsten

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 Oct 2020 14:20:36 -0500

Off-list reply.

I'm happy to hook you up with the person who did this exact evaluation 
for Mozilla when they decided to retire IRC (for many of the same 
reasons that the IETF needs to move off of Jabber). The punchline is 
that they finally settled on Matrix, but there was a lot of really 
detailed work that he did which could probably inform what y'all are doing.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 Oct 2020 14:21:47 -0500

Sorry for the noise, folks. I *meant* to send this directly to Robert. :)

/a

On 10/1/2020 2:20 PM, Adam Roach wrote:
> ___________________________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to [email-masked]
>
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to [email-masked]

---

From: Matthew Hodgson <[email-masked]>
Date: Fri, 2 Oct 2020 00:17:10 +0100

> OMG what is that riot-bot and why does it have to bother me with loud fake music.

Apologies: this was a config error - riot-bot is an old and clunky 
"welcome bot" that we retired months ago, but apparently the sample 
config for Element is stale and so it got accidentally pulled into this 
trial deployment.  The config is now fixed.

In other news, I'm the project lead for Matrix and we're super excited 
that IETF is trialling a deployment.  Folks at IETF-101 in London might 
dimly remember me doing a lightning talk to explain the project's 
mission, which is to provide an open standard for decentralised pubsub, 
with E2EE and decentralised message history.  It's like a more realtime 
version of NNTP, with open federation, freeform data, E2EE and byzantine 
fault tolerance.

The protocol currently evolves using an open governance model under the 
aegis of The Matrix.org Foundation (a UK non-profit; 
https://matrix.org/foundation); with the spec itself living at 
https://matrix.org/docs/spec and the various proposed spec changes in 
flight at https://matrix.org/docs/spec/proposals. Once the biggest 
remaining bits of Matrix are resolved (hierarchical groups, threads, 
extensible profiles and extensible messages) then we hope to snapshot 
the standard for the longterm within a dedicated independent standards 
body such as IETF, assuming interest.

Matrix itself is a global open network of about 22M users spread over 
 >50K instances, ranging from the French govt to Mozilla, Wikimedia, KDE 
and countless smaller/personal servers.  We're also in the process of 
natively bridging Gitter into the network 
(https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matrix).

Finally, in terms of clients: https://matrix-trial1.ietf.org is an 
instance of Element Web (a flagship client we build as 
https://element.io, the startup the Matrix core team formed in order to 
fund Matrix) - but there are *many* alternative excellent Matrix clients 
out there if Element isn't to your taste, e.g. weechat-matrix for TUI, 
or the incredibly light-weight Hydrogen client (alpha at 
https://hydrogen.element.io).

We'd love for the trial to be successful, and are very happy to 
tweak/fix/build things based on any feedback folks have.  For instance, 
the a11y support in Element is entirely thanks to Mozilla's feedback.  
The whole project is open source (Apache licensed) and we also very 
gladly accept contributions (e.g. all the i18n in Element was a 
community contribution).  There's currently some major work going on 
with improved groups, notifications and threading which hasn't landed in 
mainline Element, so if we need to hustle to get that merged so you can 
play with it please yell loudly and let us know.  I'll be hanging around 
in #trial1-feedback:matrix-trial1.ietf.org to answer any feedback, or 
you can find me at @matthew:matrix.org.

thanks,

Matthew

-- 

Matthew Hodgson
Matrix.org

---

From: Matthew Hodgson <[email-masked]>
Date: Fri, 2 Oct 2020 00:43:34 +0100

> models in the two applications are so different.

It's true that Zulip<->Matrix bridging is unsatisfactory currently.  
Matrix actually has Zulip-style threading already under the hood 
(MSC2326: 
https://github.com/matrix-org/matrix-doc/blob/matthew/msc2326/proposals/2326-label-based-filtering.md), 
but Element and other clients haven't yet implemented UI for it. This 
should change in future however.

> as an option as we continue to gather more feedback.

On the other hand, XMPP<->Matrix bridging (and IRC<->Matrix bridging) is 
pretty good, and we maintain and run public bridges for both - which 
could provide continuity for those using Jabber.

M

-- 
Matthew Hodgson
Matrix.org

---

From: Lars Eggert <[email-masked]>
Date: Fri, 2 Oct 2020 10:19:04 +0300

Hi,

On 2020-10-1, at 17:25, Robert Sparks <[email-masked]> wrote:
> zulip-trial1.ietf.org.

FWIW, my mail server is rejecting the account creation email from Zulip:

2020-10-02T10:16:29+03:00 Sampo postfix/smtpd[29630]: NOQUEUE: reject: RCPT from unknown[2001:1900:3001:11::23]: 450 4.7.25 Client host rejected: cannot find your hostname, [2001:1900:3001:11::23]; from=<[email-masked]> to=<[email-masked]> proto=ESMTP helo=<zulip-trial1.ietf.org>

Lars

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Oct 2020 11:20:29 +0200

> FWIW, my mail server is rejecting the account creation email from Zulip:

Same for me (I don’t have an error message, but I don’t get the mails either).

Grüße, Carsten

---

From: Matthew Hodgson <[email-masked]>
Date: Fri, 2 Oct 2020 14:24:59 +0100

On 02/10/2020 00:43, Matthew Hodgson wrote:

> On the other hand, XMPP<->Matrix bridging (and IRC<->Matrix bridging) 
> is pretty good, and we maintain and run public bridges for both - 
> which could provide continuity for those using Jabber.

To illustrate this, we've pointed 
xmpp:[email-masked] (the public XMPP 
bridge that we run on the matrix.org server) through to 
#trial1-feedback:matrix-trial1.ietf.org on Matrix for those who prefer XMPP.

M

-- 
Matthew Hodgson
Matrix.org

---

From: Johanna S <[email-masked]>
Date: Fri, 2 Oct 2020 13:44:24 +0200

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. 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.

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 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.

Johanna

[1] https://github.com/matrix-org/matrix-bifrost/issues/53

---

From: Glen <[email-masked]>
Date: Fri, 2 Oct 2020 08:40:08 -0700

I will poke the reverse DNS people about this, and I will see if I can 
come up with a quicker solution for this today.

Glen

---

From: Glen <[email-masked]>
Date: Fri, 2 Oct 2020 15:47:31 -0700

I've changed the email routing on the Zulip instance, and both of you 
should have received your messages just now.  Future email *should* 
work, and we'll keep an eye on it...

Glen

---

From: Kim Alvefur <[email-masked]>
Date: Sat, 3 Oct 2020 01:58:49 +0200

Hi,

>#trial1-feedback:matrix-trial1.ietf.org on Matrix for those who prefer 

It does not appear to be working, getting a cancel:service-unavailable
error back.

-- 
Kim "Zash" Alvefur
XMPP Standards Foundation Council member
Prosŏdy IM server developer

---

From: Matthew Hodgson <[email-masked]>
Date: Sat, 3 Oct 2020 19:59:12 +0100

> It does not appear to be working, getting a cancel:service-unavailable

Ugh, sorry - typo on my side; the correct JID for the MUC is 
xmpp:[email-masked].  I just tested from 
Adium and it seems to be working correctly.

M

-- 
Matthew Hodgson
Matrix.org

---

From: Matthew Hodgson <[email-masked]>
Date: Sat, 3 Oct 2020 20:51:17 +0100

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

> 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

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).

> 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.

> 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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 5 Oct 2020 09:33:46 +0300

Hi,

On 2020-10-3, at 1:47, Glen <[email-masked]> wrote:
> I've changed the email routing on the Zulip instance, and both of you should have received your messages just now.  Future email *should* work, and we'll keep an eye on it...

the invitations for delivered over the weekend, but expired.

When I try and sign up again now, I get this error:

> Configuration error
> 
> It appears there are problems with the email configuration.
> 
> See /var/log/zulip/errors.log for more details on the error.
> 
> You may also want to test your email configuration, as described in the Production installation docs.
> 
> After making your changes, remember to restart the Zulip server.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 5 Oct 2020 09:34:13 +0300

> the invitations for delivered over the weekend, but expired.

s/for/were/

Lars

---

From: Dave Cridland <[email-masked]>
Date: Mon, 5 Oct 2020 11:05:04 +0100

On Sat, 3 Oct 2020 at 20:51, Matthew Hodgson <[email-masked]> wrote:

> off the cards anyway.

I certainly agree that the best course of action is to have a IM solution
that is as compatible with XMPP as possible. XMPP has, I think, served the
IETF community well over the past decade or so, and existing deployed
solutions - like Meetecho and the IETF Jabber server itself - have worked
with reasonable effectiveness. The XMPP community, vendors and independent
developers, have offered help with improving this too (and many from the
XMPP community have gone on to do wider work within the IETF world).

I, too, am unclear why we declare anything built privately on web
technologies to be the moral equivalent of an open standard technology with
specifications published through a recognised standards group and multiple
interoperable implementations. One might as well use the criteria of "It's
programmed in ANSI C".

But I'm also, I confess, bewildered that the stated aim of using the likes
of Zulip (which I've never heard of before, sorry) and Slack is that public
XMPP services are not easily found, and yet simultaneously "XMPP is off the
cards", and no public accounts will be offered.

What's the blocker to offering accounts on the IETF XMPP server and hosting
a web client?

Dave.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Oct 2020 09:49:11 -0400

Dave Cridland <[email-masked]> wrote:
    > But I'm also, I confess, bewildered that the stated aim of using the
    > likes of Zulip (which I've never heard of before, sorry) and Slack is
    > that public XMPP services are not easily found, and yet simultaneously
    > "XMPP is off the cards", and no public accounts will be offered.

    > What's the blocker to offering accounts on the IETF XMPP server and
    > hosting a web client?

+1.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Glen <[email-masked]>
Date: Mon, 5 Oct 2020 08:50:02 -0700

>>> It appears there are problems with the email configuration.

Yes -

Late last week, at the request of others, I set up email ingest (a setup 
where people can send email to the Zulip instance).  I followed the 
directions we were pointed to; however, that seems to have broken 
outbound mail for Zulip.

The reason for this breakage is that Zulip, which requires a dedicated 
server instance to run, automatically configures all of the services on 
the server, including Postfix, and rewrites the config whenever we make 
a settings change.  This time, one of the configuration directives their 
system generated was blocking all outbound mail.  I've removed that 
directive from their Postfix instance manually to allow it to send email 
again; however, if we make further Zulip changes, their system might 
rewrite what I've done (it's already done that once) and revert these 
changes.   I've made a note of that in the server notes to try to stay 
ahead of it.

I can now send outbound email again by hand from the server, and Lars 
you should have gotten the test I sent from their system... would you 
give registration one more try for me?

Glen

---

From: Jay Daley <[email-masked]>
Date: Tue, 6 Oct 2020 09:13:53 +1300

Dave

> On 5/10/2020, at 11:05 PM, Dave Cridland <[email-masked]> wrote:
> 
> 
> 
> On Sat, 3 Oct 2020 at 20:51, Matthew Hodgson <[email-masked] <mailto:[email-masked]>> wrote:
> I certainly agree that the best course of action is to have a IM solution that is as compatible with XMPP as possible. XMPP has, I think, served the IETF community well over the past decade or so, and existing deployed solutions - like Meetecho and the IETF Jabber server itself - have worked with reasonable effectiveness. The XMPP community, vendors and independent developers, have offered help with improving this too (and many from the XMPP community have gone on to do wider work within the IETF world).
> 
> I, too, am unclear why we declare anything built privately on web technologies to be the moral equivalent of an open standard technology with specifications published through a recognised standards group and multiple interoperable implementations. One might as well use the criteria of "It's programmed in ANSI C".
> 
> But I'm also, I confess, bewildered that the stated aim of using the likes of Zulip (which I've never heard of before, sorry) and Slack is that public XMPP services are not easily found, and yet simultaneously "XMPP is off the cards", and no public accounts will be offered.
> 
> What's the blocker to offering accounts on the IETF XMPP server and hosting a web client?

This was ruled out by previous IETF leadership and has remained the policy since.  Technically and operationally it would be trivial to add.

I proposed the addition of user accounts a few months ago to the IESG and the Tools Team in order to address the feedback from the IETF 107 post-meeting survey, and the main concern expressed was that they would appear to be "official" jabber accounts and therefore representative of the IETF.  By contrast the zulip and matrix instances are specifically named as trials and therefore do not incur that risk.  

As that proposal was being considered, the community introduced the IETF Slack space and there were discussions in the SHMOO WG about this whole area.  In that context it did not seem appropriate to make such a change as that might be seen as acting inconsistently with the emerging community process.

I would be interested in views on this.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 5 Oct 2020 16:22:55 -0400

> On Oct 1, 2020, at 10:25 AM, Robert Sparks <[email-masked]> 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.

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?

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).

This should be the first step.

Tom

---

From: Dave Cridland <[email-masked]>
Date: Mon, 5 Oct 2020 22:12:08 +0100

On Mon, 5 Oct 2020 at 21:13, Jay Daley <[email-masked]> wrote:

> This was ruled out by previous IETF leadership and has remained the policy
> since.  Technically and operationally it would be trivial to add.
>
> I proposed the addition of user accounts a few months ago to the IESG and
> the Tools Team in order to address the feedback from the IETF 107
> post-meeting survey, and the main concern expressed was that they would
> appear to be "official" jabber accounts and therefore representative of the
> IETF.  By contrast the zulip and matrix instances are specifically named as
> trials and therefore do not incur that risk.
>
>
So the problem with using an existing service is that it may be
inadvertently considered an official stance of the IETF despite an official
statement to the contrary, whereas explicitly ruling it out, while that is
a stated official stance of the IETF, is not to be considered to mean
anything? I'm so glad you have made this crystal clear to me.

It is possible to place an XMPP service on a domain other than ietf.org,
such as, oh, I don't know, perhaps "trial.ietf.org", if the idea is really
to avoid the impression that the IETF's use of its own protocols is somehow
an approach worth following.

> As that proposal was being considered, the community introduced the IETF
> Slack space and there were discussions in the SHMOO WG about this whole
> area.  In that context it did not seem appropriate to make such a change as
> that might be seen as acting inconsistently with the emerging community
> process.
>

---

From: Jay Daley <[email-masked]>
Date: Tue, 6 Oct 2020 10:29:46 +1300

> On 6/10/2020, at 10:12 AM, Dave Cridland <[email-masked]> wrote:
> 
> 
> 
> On Mon, 5 Oct 2020 at 21:13, Jay Daley <[email-masked] <mailto:[email-masked]>> wrote:
> Dave
> 
>> On 5/10/2020, at 11:05 PM, Dave Cridland <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> So the problem with using an existing service is that it may be inadvertently considered an official stance of the IETF despite an official statement to the contrary, whereas explicitly ruling it out, while that is a stated official stance of the IETF, is not to be considered to mean anything? I'm so glad you have made this crystal clear to me.
> 
> It is possible to place an XMPP service on a domain other than ietf.org <http://ietf.org/>, such as, oh, I don't know, perhaps "trial.ietf.org <http://trial.ietf.org/>", if the idea is really to avoid the impression that the IETF's use of its own protocols is somehow an approach worth following.

I will let the Tools Team respond to that, other than to note that exactly the same point could have been reached without the sarcasm.

Jay

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tools-discuss <https://www.ietf.org/mailman/listinfo/tools-discuss>
>> 
>> Please report datatracker.ietf.org <http://datatracker.ietf.org/> and mailarchive.ietf.org <http://mailarchive.ietf.org/>
>> bugs at http://tools.ietf.org/tools/ietfdb <http://tools.ietf.org/tools/ietfdb>
>> or send email to [email-masked] <mailto:[email-masked]>
>> 
>> Please report tools.ietf.org <http://tools.ietf.org/> bugs at
>> http://tools.ietf.org/tools/issues <http://tools.ietf.org/tools/issues>
>> or send email to [email-masked] <mailto:[email-masked]>
> 
> -- 
> Jay Daley
> IETF Executive Director
> [email-masked] <mailto:[email-masked]>
-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Mon, 5 Oct 2020 22:36:22 +0100

On Mon, 5 Oct 2020 at 21:23, Tom Pusateri <pusateri=
[email-masked]> wrote:

> 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.
>
> 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?
>
>
XMPP is very widely used - almost every military uses it, and if an online
game uses any kind of open standard for chat it is XMPP - including
Fortnite, for example. These uses are not generally very visible, and often
not on the internet itself at all - but some are federated cases (such as
the military's use), and others are very large. Some are smaller, like that
of my own employer.

Servers are readily available, the majority of XMPP services use open
source servers, and there at least 6 actively maintained and well used
interopable implementations (for those that want to count them: ejabberd,
MongooseIM, Openfire, Tigase, Prosody, and Isode's M-Link - the latter
being the only one not to be open source). It wouldn't surprise me if there
are more; there certainly have been others.

Clients are harder, because "consumer" and "enterprise" markets are the
weakest the weakest area of use, and these tend to drive client
development - but really this is no different to email, where email
clients, and indeed the protocols they use to connect to services, are not
interoperable standards. The XMPP world normally uses a bespoke client, but
it still speaks XMPP's C2S protocol. This means that productized general
client experiences are niche, and generally driven purely by the open
source community (which does a pretty good job given the circumstances) -
again, this is essentially the same as the email world.

But Fortnite, for example, *is* an XMPP client - albeit with some kind of
game attached. If having 350 million users counts as failure, it's the kind
of failure that I'm happy to aspire to.

If XMPP can be considered to have failed, then it's that it has indeed not
persuaded the likes of Google, Facebook, and so on into open federation and
interoperability. Google did it several IM systems back, but abandoned it.
No matter what protocol the IETF chose to replace it with, it seems
unlikely that this direction, at least, will reverse - but that is not a
technical problem but a business one. Sadly, I believe the email world is
headed the same way - witness the mangling of your email address.

> 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).
>

---

From: Dave Cridland <[email-masked]>
Date: Mon, 5 Oct 2020 22:40:25 +0100

On Mon, 5 Oct 2020 at 22:29, Jay Daley <[email-masked]> wrote:

> such as, oh, I don't know, perhaps "trial.ietf.org", if the idea is
> really to avoid the impression that the IETF's use of its own protocols is
> somehow an approach worth following.
>
>
> I will let the Tools Team respond to that, other than to note that exactly
> the same point could have been reached without the sarcasm.
>
>
Perhaps so. But not, I assure you, without the exasperation.

Dave.

---

From: Matthew Wild <[email-masked]>
Date: Mon, 5 Oct 2020 22:50:31 +0100

> 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…

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 profit…

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 jabber.ietf.org 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.

Regards,
Matthew

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Oct 2020 20:38:36 -0400

Jay Daley <[email-masked]> wrote:
    > I proposed the addition of user accounts a few months ago to the IESG
    > and the Tools Team in order to address the feedback from the IETF 107
    > appear to be "official" jabber accounts and therefore representative of
    > the IETF.  By contrast the zulip and matrix instances are specifically
    > named as trials and therefore do not incur that risk.

Unless they weren't @ietf.org.
I'm sure this community has a few under utilized domains that could be used.
I think I'd even offer ox.org.

    > As that proposal was being considered, the community introduced the
    > IETF Slack space and there were discussions in the SHMOO WG about this
    > whole area.  In that context it did not seem appropriate to make such a
    > change as that might be seen as acting inconsistently with the emerging
    > community process.

    > I would be interested in views on this.

Even if we think Matrix or Tulip is so awesome that we'd want to run it
tomorrow, we probably want to host accounts on some domain.   So we run into
the same concern.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Oct 2020 08:22:41 +0200

> I proposed the addition of user accounts a few months ago to the IESG and the Tools Team in order to address the feedback from the IETF 107 post-meeting survey, and the main concern expressed was t…

Note that many of us already have an ietf.org email address, which would seem to incur the same kind of risk.  For me that would be:

cabo=[email-masked]

(except that that part of the DMARC hardening currently doesn’t quite work, but that is a different issue).

I wonder if we couldn’t do the equivalent for XMPP.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Oct 2020 12:05:25 -0400

To me, it feels that XMPP is being called a failure by the entities that want
to sell us something else.
For me, it's been a great success.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 6 Oct 2020 16:08:00 +0000

I am not trying to sell something else, but I believe XMPP is not the way most of the world does IM, and we should not be adding a barrier to participation.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Oct 2020 18:11:38 +0200

> I am not trying to sell something else, but I believe XMPP is not the way most of the world does IM, and we should not be adding a barrier to participation.

Neither is IRC, but the W3C support for IRC has been pretty successful in flattening the threshold; we emulate that (maybe without switching to IRC :-).

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2020 12:12:28 -0400

> For me, it's been a great success.

There’s no conspiracy here. XMPP has had a really high barrier to entry for use in the IETF for a long time. I’ve been asking for the IETF to run an xmpp server for a long time, and the answer has always been “no.” We’ve always been pointed to XMPP servers that have no SLA, and are operated for free on a “good luck, don’t bug me” basis. This basically means that anyone who doesn’t have a couple of hours to spend getting XMPP working is going to have trouble.

On top of that, even with a dependable server, which we don’t currently have, the clients have been languishing for years and are not being maintained. If I want to get a reliable xmpp client going on my Mac, I’m going to have to download and compile code, and I don’t actually know which code is the best bet, so chances are I’m going to have to download and compile multiple bits of code before I find one that works.

This is a really heavy lift for something I’m going to use for maybe ten hours per IETF, three IETFs per year.

If we think XMPP is really the best thing, we should spend money on it and make it actually work well, rather than just telling people to use it, and good luck.

I tend to agree that we want something that’s an open standard; Matrix seems to be a good choice in that regard, but I admit I haven’t kicked the tires sufficiently.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 6 Oct 2020 16:17:58 +0000

>   Neither is IRC, but the W3C support for IRC has been pretty successful in flattening the threshold; we emulate that (maybe without switching to IRC :-).

I am sure that the difference in memberships (W3C doesn't have many individual contributors or consultants) plays a big part.  Also, the way they have added on to IRC for agenda, votes, etc., adds to its appeal.

---

From: Matthew Wild <[email-masked]>
Date: Wed, 7 Oct 2020 19:02:57 +0100

Hi Ted,

On Tue, 6 Oct 2020 at 17:12, Ted Lemon <[email-masked]> wrote:
> On top of that, even with a dependable server, which we don’t currently
have, the clients have been languishing for years and are not being
maintained. If I want to get a reliable xmpp client going on my Mac, I’m
going to have to download and compile code, and I don’t actually know which
code is the best bet, so chances are I’m going to have to download and
compile multiple bits of code before I find one that works.
> This is a really heavy lift for something I’m going to use for maybe ten
hours per IETF, three IETFs per year.

Sorry, but I'm not sure what you are referring to. Off the top of my head I
can think of three or four Mac clients and I'm not aware that any of them
require compiling code.

I just dusted off my MacBook to confirm this, I obtained Beagle IM from the
Mac app store and joined [email-masked] within a couple of minutes.

Regards,
Matthew

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Oct 2020 14:04:44 -0400

On Oct 7, 2020, at 2:02 PM, Matthew Wild <[email-masked]> wrote:
> I just dusted off my MacBook to confirm this, I obtained Beagle IM from the Mac app store and joined [email-masked] <mailto:[email-masked]> within a couple of minutes.

That’s very cool. That was not available (or maybe just not findable with search) for IETF 108. How’s the UX?

---

From: Matthew Wild <[email-masked]>
Date: Wed, 7 Oct 2020 20:18:42 +0100

On Wed, 7 Oct 2020, 19:04 Ted Lemon, <[email-masked]> wrote:

> I just dusted off my MacBook to confirm this, I obtained Beagle IM from
> the Mac app store and joined [email-masked] within a couple of
> minutes.
>
>

My first time using it, but seems pretty sleek. Improving UX of XMPP
clients is a passion of mine (modernxmpp.org), and I did file this proposal
to improve first-time setup: https://github.com/tigase/beagle-im/issues/54

I know the developers value feedback, so encourage anyone who encounters
any problems to do the same.

Happy to field XMPP questions off-list too, as this thread is getting a bit
broad. I just wanted to highlight that there are absolutely suitable
maintained XMPP clients around, even if the docs on ietf.org could probably
do with an update to make that better known.

Regards,
Matthew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Oct 2020 09:24:24 -0400

That said, in order to make xmpp usable for IETF we would need for there to be a supported server operated by the ietf. 

> On Oct 7, 2020, at 15:19, Matthew Wild <[email-masked]> wrote:
> 
> 
>>> I just dusted off my MacBook to confirm this, I obtained Beagle IM from the Mac app store and joined [email-masked] within a couple of minutes.
>> 
> My first time using it, but seems pretty sleek. Improving UX of XMPP clients is a passion of mine (modernxmpp.org), and I did file this proposal to improve first-time setup: https://github.com/tigase/beagle-im/issues/54
> 
> I know the developers value feedback, so encourage anyone who encounters any problems to do the same.
> 
> Happy to field XMPP questions off-list too, as this thread is getting a bit broad. I just wanted to highlight that there are absolutely suitable maintained XMPP clients around, even if the docs on ietf.org could probably do with an update to make that better known.
> 
> Regards,
> Matthew