Subject: Re: IETF Slack workspace

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Aug 2020 00:00:10 -0700

On Fri, Jul 10, 2020 at 09:24:02PM -0700, Theresa Enghardt wrote:
> As an experiment, there is now a Slack workspace at https://ietf.slack.com, which provides a persistent chat platform with ad-hoc channel creation.

Is anyone preparing a review or summary of the outcome of the experiment?
(I did not participate in the experiment, myself, thus cannot contribute to
such a report.)

Thanks,

Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Aug 2020 15:31:56 +0000

>    Same-- I didn't use Slack during the week, but I would be very 
    interested to know how it went.

IETF to bcc.

Never got a definitive answer; I posted the question last week -- https://app.slack.com/client/T03SESPS0/C03SESPT6

I don't know if Theresa and Richard had specific plans.

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 4 Aug 2020 09:21:08 -0400

-Mallory

> -- 
> Mallory Knodel
> CTO, Center for Democracy and Technology
> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Theresa Enghardt <[email-masked]>
Date: Sun, 9 Aug 2020 19:36:44 -0700

Hi all,

As people have asked about a report/summary on Slack usage during IETF
108, I'd like to provide some numbers, which I looked at via the Slack
analytics feature.

I think these numbers nicely supplement the anecdotal evidence/summaries
that people have already provided:

According to its analytics page, the IETF Slack workspace currently has
218 members, 111 of which have been "weekly active members" during the
last 30 days. "Active" means that they've posted at least one message
and/or read at least one direct message or channel. (Not sure how
exactly Slack defines "weekly" here, but read on for more detailed stats.)

The daily activity statistics say that, outside of IETF 108, there's a
baseline of 20-30 daily active members (i.e., reading at least one
channel/message or posting something), and up to ~10 members are posting
messages.

The week before IETF 108, we see a ramp-up to up to 80 active members a
day (Thursday), however, there's still just about ~10 members actually
posting something on each day.
During the weekend before IETF 108, activity drops to the baseline.
Then, during IETF week, each day roughly 70-90 members were active, with
20-30 members posting each day. The peaks were on Monday and Friday. On
Saturday and Sunday after IETF, activity dropped back to the baseline.

Counting unique messages, the baseline is at roughly 10-20 messages sent
each day, on some days less (down to some days with 0 messages).
During IETF week, there was a peak on Monday (170 messages), a drop to
roughly 30-70 messages, and then another peak on Friday (435 messages).
Most messages were sent in public channels (roughly 60-90% depending on
the day), but there was some usage of direct/private messages between
members (roughly 10-35% depending on the day), and private channels (up
to 20% depending on the day).

The most popular channels were #general, with the most numbers and most
views. As the name says, there were some general discussions, e.g.,
about IETF 108 (e.g., when do rooms open, when is a good time to find
people on gather.town), about tooling and the Slack itself, and
announcements of the existence of other channels.
Other popular channels include the #chat-tools and #codesprint channels,
where some discussion/collaboration happened, as well as social
channels, such as #random for more informal chatter in general, as well
as #108newcomers and #systers for particular groups. These channels were
used to complement hallway chats at gather.town (e.g., when/where to
find them), to answer questions, and for introductions, particularly
among the newcomers.
Each of the #hotrfc108-* channels was only joined by 5 to 16 members,
and only 0 - 4 messages were sent in each channel.

To summarize, there wasn't a ton of usage, but it appears that there
were some use cases for Slack.

Best,
Theresa

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 27 Aug 2020 14:55:55 -0400

On Sat, Jul 25, 2020 at 05:15:20AM +1200, Ross Finlayson wrote:
> The very first thing that this web site does is ask for an email address.
> 
> What assurances do we have about what ???Slack, inc.??? will (or will not) do with these email addresses?

The answer is "none whatsoever" since they can change their policies 
at will.  (I'm not singling them out: all kinds of operations have already
done this, so much so that it's common/expected practice.)

I strong advise avoiding them entirely.  Mailing lists are a vastly
superior tool for collaboration -- and their archives are one of the
most stable, usable, searchable long-term solutions we have.

---rsk

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Aug 2020 15:57:35 -0400

> most stable, usable, searchable long-term solutions we have.

+1

---

From: Ali Mezgani <[email-masked]>
Date: Thu, 27 Aug 2020 21:08:25 +0100

For agility Slack is an instant and real time talking methodology.

I’m also, like mailing list but why not encourage diversity of tool to
collaborate.

Ali.

Native LABs
https://www.nativelabs.ma/

---

From: "John Levine" <[email-masked]>
Date: 27 Aug 2020 16:26:29 -0400

In article <[email-masked]> you write:
>The answer is "none whatsoever" since they can change their policies at will.

It's an experiment. If it turns out to be useful I expect the data
retention issues will be one of the things we consider going forward.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Aug 2020 16:29:55 -0400

> retention issues will be one of the things we consider going forward.

I hope not only data retention issues will be considered, but also data 
sharing with other parties via whatever means (cookies, back channels, 
fingerprinting, etc.)

Keith

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2020 00:03:36 +0200

On 2020-08-27, at 20:55, Rich Kulawiec <[email-masked]> wrote:
> The answer is "none whatsoever”

Yes.

This is somewhat mitigated by the fact that active participation in the IETF already makes public the mail address you use for that (mail archive, “author’s addresses” in the draft), so I don’t see a lot of downside to giving them out directly to another entity.

In the computer science/math department of the university, we are very careful about forcing the students into handing out PII to third parties (*), so we run our own mail, seafile, IaaS, LMS, gitlab, hackmd, mattermost, rocket-chat, etc (partially departmental, partially in the computer center).  (The university as a whole seems to be less shy about this, but that is a different issue.)  In the IETF, transparency issues may make those privacy issues mostly moot, more so than we probably would like it to be.

Grüße, Carsten

(*) Note that any third party can (and quite likely will) go evil if it goes bankrupt.  I don’t think our legal department knows why you’d want to have bankruptcy clauses in any self-respecting contract, and we wouldn’t get those from the commodity services anyway.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 28 Aug 2020 07:01:34 +0300

Because adding more tools for collaboration makes it harder, not easier, to participate.

When we deal with a technical issue, there is usually a draft. The conversation about this draft already happens in several places:
The working group mailing list
Occasionally, the IETF or last-call mailing lists
GitHub if that is where the document is developed
Physical or Meetecho WG meetings
Jabber / Meetecho chat

In order to follow the conversation about this draft, you have to be on *all* of them. If you don’t like github, some conversation is going to happen there, and you will miss it.

By adding more tools,  you increase the requirements to participate in the conversation.  A diversity of tools helps when it gives you another option to have a conversation where each conversation uses one tool.  Here we have one conversation that is happening using many tools.

Yoav

> On 27 Aug 2020, at 23:08, Ali Mezgani <[email-masked]> wrote:
> 
> I’m also, like mailing list but why not encourage diversity of tool to collaborate.
> 
> Ali.
> 
> Native LABs
> https://www.nativelabs.ma/ <https://www.nativelabs.ma/>
> 
> 
> 
> On Thu, Aug 27, 2020 at 20:58 Keith Moore <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2020 08:29:29 +0200

> By adding more tools,  you increase the requirements to participate in the conversation.  A diversity of tools helps when it gives you another option to have a conversation where each conversation…

… and much worse, having several places to choose for discussions that each have different levels of attention from different subsets of the people is bound to create factions.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 15:12:55 -0400

It feels like a major argument for slack is that offers reliable sign up for
people who don't know how to find a jabber server, and/or who are unable to
run an XMPP client.  I use pidgin/libpurple, and I know that there were times
when there were significant security issues with it.  I've heard that on
Mac that there is not really a (thick) client that has reasonable support.

So it seems to me that:
1) the IETF should run a jabber server to which we can register to using
   our DT login. (through OpenID Connect, I guess)

2) that the IETF should host one or more web based XMPP clients, possibly
   paying a license fee/support.

Slack supported XMPP in/out when it first launched, but then stopped.
I've been told that this is actually configurable on a per-workspace basis.
I don't know the truth of this.

It would ideal if Slack could XMPP s2s out to IETF jabber servers, but
I would not be surprised if this is not supported.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jared Mauch <[email-masked]>
Date: Fri, 28 Aug 2020 15:18:10 -0400

> On Aug 28, 2020, at 3:12 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> run an XMPP client.

There’s also the fact that Jabber and the multiple device presence issues make it easy for a message to be lost, or unknown if it’s actually received.  It will silently fail, and we should not expect participants in the IETF to be able to run, troubleshoot and repair a XMPP server and client set.

>  I use pidgin/libpurple, and I know that there were times

There is also the spam problem.  And if you blacklist, greylist or whitelist domains, you have the problems above.

>   our DT login. (through OpenID Connect, I guess)

This would make some sense, but then username@[email-masked] ?

> I don't know the truth of this.

This has it’s own issues, because their XMPP support didn’t notify you of channels you were added to, leading to the blind messaging problem above.

> I would not be surprised if this is not supported.

Slack model is on a pay per user model (primarily), so s2s on XMPP is not going to work right.

You can integrate slack workspaces together, lets say you have one called example1 and example2, you can link them and have shared channels.  This doesn’t really match the IETF communication model.

I have to say this:

If my kids can figure out how to do this and the IETF can’t, we’re clearly missing something, or attempting to over-engineer or over-religion it.

- Jared

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Aug 2020 15:36:13 -0400

> If my kids can figure out how to do this and the IETF can’t, we’re clearly missing something, or attempting to over-engineer or over-religion it.

Kids generally aren't concerned about a number of issues that are 
important to IETF - such as privacy or multi-platform compatibility or 
global reach or scalability to hundreds of people in the same 
conversation or reliability against loss of any messages.

But I agree that having to arrange for a jabber account and configure a 
client are a pain.

Keith

---

From: Timothy Mcsweeney <[email-masked]>
Date: Fri, 28 Aug 2020 15:37:44 -0400 (EDT)

On 08/28/2020 3:18 PM Jared Mauch <[email-masked]> wrote:

How about drop#324.ietf :-)

---

From: "John Levine" <[email-masked]>
Date: 28 Aug 2020 16:52:59 -0400

>Mac that there is not really a (thick) client that has reasonable support.

I have found that Beagle and Swift work on my Mac. The problem is more
the lack of places to set up one's XMPP account.

R's,
John

---

From: Jared Mauch <[email-masked]>
Date: Fri, 28 Aug 2020 17:09:24 -0400

Thanks for making my point. That the IETF is open so while people may want privacy we know who the participants are and how the note well applies. 

This isn't some idealistic fantasy land, we are still bound by some practical bits which often seem to be lost by the folks who get high on certain remarks. 

Operators and users need things that work. The IETF reliance on XMPP needs to go the way or directed broadcast and mode 7 NTP on public networks. 

The meet echo integration was great this time, and if we build more tools like this they will gain acceptance. 

I can't use XMPP due to the a variety of reasons about how poorly it works for a user and administrator. 

Things like slack are successful because they work for the users. 

When the first RF  is published by an anonymous user In an anonymous WG and is covered by the note well let me know. 

Sent from my iCar

> On Aug 28, 2020, at 3:36 PM, Keith Moore <[email-masked]> wrote:
> 
> Kids generally aren't concerned about a number of issues that are important to IETF - such as privacy

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Aug 2020 17:16:34 -0400

> Things like slack are successful because they work for the users.

As a former user of Slack, I beg to differ.   It's a thoroughly 
dysfunctional means of collaboration.   IMO, things like Slack are fads.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Aug 2020 17:24:05 -0400

> the lack of places to set up one's XMPP account.

That, and you have to find a suitable client, and you have to set it 
up.   There are three hoops to jump through, which you're generally 
trying to do after the meeting starts.

If we used XMPP all the time it wouldn't be a problem, but most of us don't.

If we want our protocols to be successful, maybe we should pay more 
attention to making configuration easy, and user-friendly diagnostics.

While I very much support open standards, I must admit that the 
proprietary solutions have some competitive advantages.   Users don't 
have to find a client and a service provider separately and make them 
work together.   When there's a problem, users have one stop shopping 
for support (if there is support).   And it's easier to market a 
brand-named bundled service than it is to market an open standard.

Keith

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Aug 2020 23:28:24 +0200

IMO most collaboration tools I am aware of are pretty badly architected.

Choice of user front end should be local user selection not something
enforced by tool. Message should be send to a db and how each user selects
to receive it and respond to should be only his local matter.

One at some time of the day may prefer email, some like web interface like
slack, some like chat etc .... a bit later he may choose to adjust the
front end such that say after hours messages to him go to email vs live
chat.

Today all tools have a globally unified front end which by design is a
fundamental mistake.

Best,
Robert.