Change Drupal Slack allowed/installed apps

Hi, I'm an admin of the Drupal Slack.
I've been thinking about removing the ToDo integration anyway, doesn't seem that anyone is using it.

No other thoughts at the moment, currently waiting to see how #2863181: Druplicon's purpose changed - block it as we consider purpose/use of irc bot in the future plays out.

I don't think we should use the webhooks that send the data to 3rd parties.

The bot will be back online today or tomorrow pending a convo with freenode. I did write a quick slack integration for it, so the same karma and factoids will work over slack and irc.

Adding webhooks that are not owned or run by the DA is not something I would be in support of. That is how we got into this issue to start with.

Created: https://www.drupal.org/node/2864658 - "Modernize the IRC Drupalbot"

+1 for adding ingoing/outgoing Slack hooks for Riot/Matrix.

This is an integration that removes many of the limitations of Slack -- no 10,000 message history limit, search across the full history (after the integration is created), no onerous signup requirement, and the room(s) are present/hosted by all Matrix "homeservers" that have a user in the room. E.g. my company has matrix.freelock.com, and I'm currently bridged into #drupal, #drupal-commerce, #drupal-migrate, #drupal-search-api IRC rooms -- these rooms now exist on matrix.freelock.com and matrix.org (where the bridge is running).

Currently Riot hosts Slack and IRC bridges for free. The bridges are free, open source, but it is a private company providing the hosting for the actual bridge. The Matrix rooms are distributed. The Slack rooms are ... in Slack, obviously. The bridge itself is hosted by Riot -- but the DA can choose to run their own bridge using the same code, and have full control.

Furthermore, Matrix can bridge both Slack and IRC into the same rooms, much better than the Slack/IRC integration. This allows IRC users to participate in Slack rooms, pretty much transparently, without needing to join Slack.

Given the privacy issues here, I am closing this as won't fix.

Seriously? You're OK with a completely proprietary communications medium that the DA has absolutely no control over, that is actively hostile to open source communities -- but not okay with adding an open source bridge that makes it possible to participate in the Slack conversations on a fully open source platform that the DA (or anyone else) can set up and self-host?

I would say, rather than making a Slack webhook "closed/won't fix" we should make the Slack channels themselves "Closed/Won't fix." Those of us that prefer open source projects don't use the Slack channels as it is, so it's excluding a huge part of the community. Much better to send the conversations back to IRC...

I think @freelock is right and we should get to a decision regarding Slack and other "fragmentations" of the community.

Let's keep the discussion in https://www.drupal.org/node/2490332

I'd just like to clarify that the DA does not control any of the communities communication mediums outside of drupal.org. They don't control the Slack teams that have been created, IRC, meetup.com groups, most twitter feeds besides their own, etc.

I also don't think this issue should have been closed down.

The IRC issue has no structural means of coming to a conclusion. Slack is the defacto alternative, a decision made without a conclusion to that issue. By overruling opening channels up it continues to be the closed alternative overruling all the other discussion.

The purpose of bridging Slack to Matrix is to open channels up. So for those channels (it need not be all, just opt-in) that are bridged the purpose is to make them more public, and easier to access, to more people. No invite needed. Are there specific security concerns to that?
[You can also make private Matrix channels, but I'd say that is outside of scope here].

Privacy issues must be considered only for private channels

I take issue with this particular point. Privacy isn't just about something being secret. There are also certain expectations about the medium being used and how your words are spread. The Slack team is public in the sense that anyone can join and see, but many might assume what is said isn't leaving the confines of the Slack channel. With the recent drama we've already had problems with people taking screenshots of things said in-channel and broadcasting it on Twitter. That is highly unacceptable.

I want to be as neutral as possible on all Slack matters, and make as few decisions as humanly possible, but I'm fully willing to err as obnoxiously as possible on the side of caution and privacy. With my point being that this isn't just a case of "It's the internet, join all the channels, no brainer, duh." There are some other things to consider, which everyone is still mulling over. For instance, we will need some notification to let people know. This isn't something people opted-in to when first joining. Perhaps many will object.

These concerns are also why I've been against archiving the channel history. Most of the conversation is off the cuff, and doesn't need to be stored in a vault for all of humanity. If you lose a helpful tip someone made a week ago, too bad. Write it down. Most of the stupid stuff people are saying in the middle of arguments doesn't need to be saved for posterity, and it doesn't need to be broadcast to every channel that exists on the internet. I know that comments on issues, for example, do stay forever, and can be indexed by search engines, etc. But that is also why most people put at least a little thought into what they write before submitting. That doesn't happen in chat applications.

Regarding the fragmentation, this is what a decentralized community looks like, which many people say they prefer. There isn't even one Slack. The one used by camp/con organizers is a different one, many regional groups have their own, there is a separate one for frontend (which gets more frontend traffic than this one.) That on top of gdo, forums, issue, twitter, reddit, and everything else.

Those of us that prefer open source projects don't use the Slack channels as it is

Given the won't fix, I'm now an active supporter of dropping all of Slack and instead support Matrix.org.

I can agree with both of these statements. Here is the thing. There is no official communication channel other than what is on drupal.org. If there is an alternative that someone wants to setup and let people join, feel free. If it works well, lots of people, me included, will be happy to leave a propriety system. Remember, there are lots of people who never joined IRC, because they just straight hated using it. Let's not pretend it was the one true place for all conversation.

Short answer: There are pros and cons, but everyone needs to realize there is a lot to consider when managing how we communicate.

p.s. I would also echo mlhess' comment about being careful about adding webhooks from, I'll use the word unvetted, sources. I don't know what steps are need to further investigate or policy considerations, but I happily defer to the head of the security team on that.

I'm setting the status to postponed for now. It would be good if the webhooks are at least vetted, and maybe see if they are something DA staff can be responsible for.

I don't think there is a response required from the security team. While I am a member of the security team, my comments here were not on behalf of them.

I do think this needs to wait for #2490332: Evaluate whether to replace drupal IRC channels with another communication medium and then have a complete solution that is not a bandaid to bridge more than one community into another community. (community is in this instance is really user base of communications tool)

So postponed for now, but my guess is this will end up not being done, as we won't end up with slack as the official communication channel.

+1 for adding ingoing/outgoing Slack hooks for Matrix.

See #2885060: Drupal Chat Bridges IRC <-> Matrix <-> Slack
I made an overview of channels, each with the IRC and slack rooms.

As my note on this, if privacy is the issue, shouldn't we just set a disclaimer on each slack channel telling the room is bridged, with a link to a matrix client? Chance is many people start using a riot web client, same benefits at least. You always stay online, can read through history after you were afk.

@mlhess

I do think this needs to wait for #2490332: Evaluate whether to replace drupal IRC channels with another communication medium and then have a complete solution that is not a bandaid to bridge more than one community into another community. (community is in this instance is really user base of communications tool)

That is exactly what those of us advocating bridging to Matrix are arguing for -- a complete solution. However, we're not trying to force anyone to change their preferred communications tool -- we're trying to allow people to stay on the platform they prefer, IRC, Matrix, or Slack.

Right now the community is split in half, between Slack and IRC. Matrix users are fully on IRC already, it's not another silo. All we're asking is to essentially let people who like using Slack to keep using it, while not excluding the rest of us.

This can be done today, easily -- all that is necessary is the cooperation of an admin of the Slack rooms to use two Slack integrations for the bridge.

What is the downside of this? Tons of upside. No downside. Why the resistance?

I am also a little bit annoyed by having to check all the platforms to take part of the community. I don't understand how the plusplus bot (to name one) takes precedence re-connecting the community that's now scattered. Out of frustration I may stop checking Slack or IRC and decide only for one of them. Other people may feel like that. Clicking a bunch of buttons in the Slack config can fix that and let everyone use the client they prefer.

I agree with @freelock, I also wonder Why the resistance?

Speaking as someone who is totally amenable to the idea of a bridging solution in principle - I think the concern expressed in #2864161-16: Change Drupal Slack allowed/installed apps hasn't been totally addressed.

There is a generalized concern that people's words will be captured for eternity when under the IRC model at least they had some expectation of them being temporary and going away. There's also the expressed concern of things being screenshot-ed and paraded about during moments of drama.

Now - it's 100% fair to say - "...but hestenet! - people have been using IRC bouncers to record full channel history on an individual basis forever!"
- that's true, but the underlying potential for some abuse is simmering there.

Then again, it feels like the momentum is behind a bridging solution is strong, and the 'evaluate alternatives' thread (even for non bridging solutions) all includes options that would retain history as major features.

I think that means we need to answer some final questions on a policy level:

1. Can we put a message-of-the-day across *all bridges* warning folks that history is now saved publicly?
2. Can we update our community code of conduct to explicitly ban 'screen-shot-shaming'?
3. What kind of kick/ban control can we manage once we start bridging across a bunch of solutions?

I think if we can answer all of these in a satisfactory way, that would help allay the caution about this.

There is a generalized concern that people's words will be captured for eternity when under the IRC model at least they had some expectation of them being temporary and going away.

We had http://druplicon.info logging many Drupal channels for a long time, publicly accessible and searchable. It's not only about bouncers or local logs. It was only recently after #2863181: Druplicon's purpose changed - block it as we consider purpose/use of irc bot in the future that the logging feature disappeared. None of the logged channels I participated in had disclaimers, but that could be a nice addition.

My take is, let's bridge the community back together, and then let's address these complex and not new concerns.

Does that make sense?

Couple of echoing points here:

This doesn't need to wait for #2490332: Evaluate whether to replace drupal IRC channels with another communication medium. If anything I doubt anything will ever truly reach a consensus there until there is a working model in place. Maybe not even then.

Slack already keeps history (if memory serves, files cannot even be deleted there). The primary #drupal* channels have had a searchable history for as long as I can remember, this only changed now. I don't know if Slack has the ability to post room messages that are unobtrusive (if so then a link to a room privacy policy should do), but it should be expected that anything in a room is recorded.

I am setting this back to active. Management of Slack needs to be sorted. It looks like incoming webhooks is already active and I am unsure of much of the rest.

let's bridge the community back together

I feel the need to challenge this part a bit. Why say this as if it is fact? From what I've seen, anecdotally, a lot of people in Slack are not/were not commonly using IRC. We need to please stop pretending that everyone was on IRC. Only a very small subset of people involved in Drupal were regularly on IRC. It is often sited as something newbie and non-tech people shied away from completely. I'm not seeing "scattering" as a strong argument when for so long those people had little or no means for participating with the community, with no one knocking down that barrier. So I think everyone is fairly accustomed to multichannel communication by now. I have yet to see people banging down the door to bridge channels except for the people involved in these issues, which still have not addressed other concerns?

What I have been focusing on as discussions like this come up more in different places (beyond the Slack discussion,) is some policy for how we might/should handle communications; with regard to privacy, control, moderation, et al. People arguing in favor keep discussing technology and that alone. The hesitation hasn't been about the technical component.

I'll amend my previous comment a bit. As it relates to the technology component, it would help if what this all looks like was outlined. For example, the booting of accounts from one medium into the other. That appeared possible, but wasn't clear if it was permanent. How the accounts look when seen from one medium or the other. Name conflicts. What the user experience is actually like for people on different ends. I honestly don't know what any of that looks like, before passing judgement on specific parts of it. Maybe a chart or screenshots are needed?

@Frob

Slack already keeps history (if memory serves, files cannot even be deleted there). The primary #drupal* channels have had a searchable history for as long as I can remember, this only changed now. I don't know if Slack has the ability to post room messages that are unobtrusive (if so then a link to a room privacy policy should do), but it should be expected that anything in a room is recorded.

Slack does keep full history, and apparently this can be enabled at some point in the future if somebody were to step up and pay for more than a free account... so as it is, we're having to trust a 3rd party with this info already.

However, this doesn't mean search is useful. They only allow you to view and search the past 10K messages -- which in busy groups is pretty much worthless.

@davidhernandez Technology answers:

- we have already set up the bridges between many IRC rooms and Matrix. The IRC bridges sync ops, topics, kicks and bans between IRC and Matrix. Tim Plunkett used me as a test a while back, successfully kicked me in Matrix from IRC.

- The Slack bridge is nowhere near as full a solution -- it uses an outgoing webhook to send all Slack messages to the corresponding Matrix room, and an incoming webhook to send all Matrix messages to the Slack room. In Slack, the messages are posted by "APP", but they do show the avatar and name from the Matrix user account. In Matrix, Slack "ghost users" appear whenever somebody speaks. The membership lists are not synchronized, but as people speak their account appears on the other side. Direct messages do not work, and I don't think any ops, kicks, or bans go across the bridge -- these would need to be done on both sides of the bridge.

So this would essentially be two sides -- the Slack side, and the IRC/Matrix side -- if there was abuse, it would need to be dealt with on the side that it's coming from. And this would make the main commentary in each room go to both sides, allowing group conversations from whichever platforms, although for private conversations people would need to go to the same side (PMs do work between Matrix and IRC).

People questions:

- "... some policy for how we might/should handle communications; with regard to privacy, control, moderation, et al." -- pretty much the same as we do now. Does anyone really have an answer for screenshots of a chat? Or an assumption that what they write won't be dredged up by somebody in the future? (If they really want to talk privately, Matrix's End-to-end encryption is far more likely to at least ensure no outsider can see a message). The whole reason we're discussing here is to make sure that people who should have control/moderation get added appropriately.

It's not like this is irreversible, either -- any Slack (or Matrix) admin can pull the webhooks if things went south...

As it is, people have certainly switched from IRC to Slack, by the very numbers. And yet there are many who find Slack to be a hostile place for open source.

We need to please stop pretending that everyone was on IRC.

In the before time, in the long long ago, IRC was all that there was. So yes, by default, if you wanted to chat you had to use IRC. Therefore, at one time everyone was on IRC because that is the only place they could go for live real time chat. IRC still is the official chat "I give support on IRC" is an option on our drupal profiles for this reason.

As it is, people have certainly switched from IRC to Slack, by the very numbers. And yet there are many who find Slack to be a hostile place for open source.

Slack is a switch of convenience for people who are using slack for work. But that doesn't mean that it doesn't exist. With so many people on it, it would be a shame to just try and shut it down after #2490332: Evaluate whether to replace drupal IRC channels with another communication medium is resolved.

@davidhernadez, as far as I can tell, @freelock has done a good job of answering your questions. If not can you give us an ordered list of specific questions so we can work toward a solution?

edit: fixed typo

davidhernandez:

I'd just like to clarify that the DA does not control any of the communities communication mediums outside of drupal.org. They don't control the Slack teams that have been created, IRC, meetup.com groups, most twitter feeds besides their own, etc.

Seriously?
What kind of illogical fallacy is it. Terming so reflects your poor understanding of Drupal Association and Drupal communities in general.

Just because if the ownership of social media handles/instant messaging platforms etc of regional Drupal Communities are not in the DA staff, does it mean such platforms can be used for anything against code of conduct and DA has no right to set guidelines?

When a Slack team druaplslack.herokuapp.com is being promoted as the main slack group of Drupal, claiming that rights on that slack group are upto the admin of that slack team is seriously against the community and such a practice of privatization of community platforms should be discouraged as it harms the community as a whole.

Slack is announced heavily in https://www.drupal.org/slack, which is a D.O. main page.

Re: #2864161-30: Change Drupal Slack allowed/installed apps

I believe the point David is making is not that we at the DA can't set guidelines or a code of conduct, but more literally that we don't control (in the sense of have administrative and configuration access) most of these new community channels that have sprung up.

And this has always been true to a certain extent. Just because Drupal.org promotes a variety of community channels and gathering places does not mean that they are all 'official' (see StackExchange or Reddit as similar examples).

One very important difference is that participation in all of those various channels has been up to individual users who chose to use them. Bridging solutions make participation in these additional clients/platforms/protocols involuntary - which means the standard for implementing them must be higher, and must address these concerns.

I'm speaking here primarily as a community member, not as my role in the DA, because I think before the DA endorses anything we want to see the community arrive at a mutually acceptable solution.

The sky won't fall while we take a breath and take some extra time to examine these issues critically.

In particular - and speaking just as one person - I'd like to understand concrete solutions:

• to prevent impersonation (an issue that has been actively exploited to harm members of the community in recent weeks)
• user administration/ban enforcement
• and enforcing privacy controls for individuals to the greatest extent possible (acknowledging that copy and paste has always been and always will be an end-run around that)

I worry that many of these solutions can't be solved without centralizing these solutions in some way (through a DA controlled third party account, bridging server, and/or authentication mechanism), all of which are systems that don't presently exist, and would have to be added to our roadmap.

At the very least we need a clear understanding how the above issues would be managed from:

• a policy perspective
• an architectural perspective
• and an understanding of who/what entities(The DA? Current community administrators?) would need direct configuration/administrative access in order to enforce any of this.

Hey hestenet, the sky won't indeed fall, so we can take our time to find a good solution.

About the issue of impersonation, by default, a user has one account, with a user ID like @betz:matrix.org
But a user could be impersonated by changing the 'display name', which you always can edit.
We did try to impersonate each other by the display name, and attached an image of how it looks.
So good protection against impersonating i guess.

Another thing is, Matthew, the main developer once told he was willing to setup a private drupal matrix server.
So we could have our own @betz:drupal.org accounts, with the drupal.org as homeserver.
And for now, there is an LDAP authentication tool, which we eventually could have running, so all drupal.org accounts have a matrix account.

Or we implement another authentication mechanism, that would work with drupal.org
We had this in mind for a sprint on Drupalcon Vienna, but no preparation was done yet.

BTW, on the previous image, it was me trying to impersonate ekes from my @betz:matrix.org account.

Therefore, at one time everyone was on IRC because that is the only place they could go for live real time chat.

You are making an assumption that everyone participated in real time chat. That was my point. Many did not, because they found IRC to be an impassible barrier.

Another thing interesting for the matrix case is federation.
A room, let's say #contribute:drupal.org is hosted on matrix.org hardware, so what Matthew proposed.
But if we one day would setup our own matrix server, we just change a DNS SRV record to our own matrix server.
This way, you could easily migrate to another server, while keeping users and room history.
A room can even have multiple aliases, like #contribute:drupal.org, #contribution:drupal.org or even federated on another server like #drupal-contribute:foo.bar

See https://github.com/matrix-org/synapse#setting-up-federation

@davidhernadez

So yes, by default, if you wanted to chat you had to use IRC.

Notice the "if". If you wanted to chat the only option was IRC. Impassible or not, it was the only option. Not the only official option, but it was the only real option for real time chat on the internet. If they couldn't pass that barrier then they couldn't chat. I am not saying it was a good thing, but that is the way it was.

I am not assuming that everyone participated in real time chat, some chose to use the forum, some chose to ignore the community altogether. But we cannot ignore what the IRC legacy was. Or discount that those that were willing to get past the IRC barrier need to also be thought of now.

I am putting forward a counter argument here:

a lot of people in Slack are not/were not commonly using IRC

Why would someone leave a platform that they chose to spend so much time in getting working in the first place. It makes perfect sense that most people who have put in that investment are not going to be willing to just abandon it for something new that is not officially supported (like the slack channels).

As an IRC user myself, the experience after the barrier to entry is really good and I will likely still use IRC and rely on the martix bridge, because I am involved in other open source communities that use IRC. We shouldn't be trying to discount this effort. Matrix has already bridged the IRC gap very well. There might be some more bugs to work out, but there always are and we cannot let perfect become the enemy of good. All that is being asked it to bring the slack folks back in too.

I still don't know what you mean by officially supported. There is no officially supported Slack team. The one with the name "drupal" was created by community members. If you looked at the Slack documentation page on drupal.org there are many Slack teams listed there. I'm currently logged into three of them. Anyone could create another and use it. You are't limited to this one. It just has critical mass. Just like whomever created and now moderates the Reddit subreddit, meetup.com groups, or any of the other places. If you don't want to use it, don't. If you want to stick with IRC, go ahead. No one is telling you not to. Everyone is free to control how they participate.

we cannot let perfect become the enemy of good

This is where we disagree. This isn't about simply technical issues. There are privacy concerns, control concerns, moderations concerns, issues that can enable harassment, impersonation, and other things. When that is the case I will absolutely let perfection be the goal, because you can't always undo damage that is done. So I see no rush to do something if we can't guarantee it is done right, or should be done at all.

I said:

something new that is not officially supported (like the slack channels)

As in, the slack channels are not officially supported. The IRC rooms are officially supported. There is and IRC Component in the d.o infrastructure. I have never called the Slack channel anything other than a community movement. This is yet another reason to move forward on this issue.

There are privacy concerns, control concerns, moderations concerns, issues that can enable harassment, impersonation, and other things.

Please bring up the specifics. Many of these problems exist currently for the IRC rooms. Nothing is perfect, and if nothing is done because we wait for perfection then all that will happen is a lack of control. I agree that these concerns should be voiced and address and any problems need to be resolved. But doing nothing cannot be the option, and the status quo here has been to do nothing.

@davidhernandez, @hestenet, please respond to @betz and @freelock who have been attempting to work through your concerns but who you have ignored. So far, objections have been raised, responses have been written but no action or plan or responses to the response have been made.

I have correlated the current conversation below:

@hestenet wrote:

1. to prevent impersonation (an issue that has been actively exploited to harm members of the community in recent weeks)
2. user administration/ban enforcement
3. and enforcing privacy controls for individuals to the greatest extent possible (acknowledging that copy and paste has always been and always will be an end-run around that)
4. I worry that many of these solutions can't be solved without centralizing these solutions in some way (through a DA controlled third party account, bridging server, and/or authentication mechanism), all of which are systems that don't presently exist, and would have to be added to our roadmap.

@betz: replied:

About the issue of impersonation, by default, a user has one account, with a user ID like @betz:matrix.org
But a user could be impersonated by changing the 'display name', which you always can edit.
We did try to impersonate each other by the display name, and attached an image of how it looks.
So good protection against impersonating i guess.

Another thing is, Matthew, the main developer once told he was willing to setup a private drupal matrix server.
So we could have our own @betz:drupal.org accounts, with the drupal.org as homeserver.
And for now, there is an LDAP authentication tool, which we eventually could have running, so all drupal.org accounts have a matrix account.

Or we implement another authentication mechanism, that would work with drupal.org
We had this in mind for a sprint on Drupalcon Vienna, but no preparation was done yet.

At the very least we need a clear understanding how the above issues would be managed from:

• a policy perspective
• an architectural perspective
• and an understanding of who/what entities(The DA? Current community administrators?) would need direct configuration/administrative access in order to enforce any of this.

@davidhernandez; Wrote:
- 5. "... some policy for how we might/should handle communications; with regard to privacy, control, moderation, et al."

@freelock replied:
-- pretty much the same as we do now. Does anyone really have an answer for screenshots of a chat? Or an assumption that what they write won't be dredged up by somebody in the future? (If they really want to talk privately, Matrix's End-to-end encryption is far more likely to at least ensure no outsider can see a message). The whole reason we're discussing here is to make sure that people who should have control/moderation get added appropriately.

It's not like this is irreversible, either -- any Slack (or Matrix) admin can pull the webhooks if things went south...

@hestenet wrote: (not yet addressed)

One very important difference is that participation in all of those various channels has been up to individual users who chose to use them. Bridging solutions make participation in these additional clients/platforms/protocols involuntary - which means the standard for implementing them must be higher, and must address these concerns.

I am not sure about why the involuntary nature makes these concerns higher (it isn't as though this becomes more fragile or the addition of a bridge makes impersonation easier). But this adding involuntary participation is something that should be discussed.

I added the ordered list markers so that we can better tell what everyone is talking about.

At now Matrix.org release a new 0.2 version of Slack bridge that implement new way of bridging via native Slack app without using Incoming and Outgoing webhooks.
Webhooks way was have many privacy questions from workspace users, new way via Slack app have limited list of permissions and much easier to setup.

So via new way of Matrix <-> Slack integration no private info and private rooms data will be shared to Matrix.