Problem/Motivation

At core conversation session by @kgoel at DrupalCon LA , 2015 on "Pain points of learning and contributing in the Drupal community" , several people mentioned that they don't like IRC and they don't get on IRC.

During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC.

Problems with chat, regardless of technology used

  • Too much overhead to add new channels for ongoing projects.
  • Many channels don’t have ownership or moderation
  • No integration with our projects. Channels are made independently from the project
  • Cognitive load each time you return to a channel to see what's changed
  • Chat isn't necessarily the most effective way of communicating (versus issue queues, audio/video or face to face)
  • It risks being a significant time sink / distraction
  • Drupal is a global project and some contributors will always be in a difficult timezone compared to others
  • People's ability to participate in chat is affected by whether English is their first language

Concerns people have voiced about IRC

  • There is no scroll back/history/asynchronous conversation native to the platform (requires a proxy such as bip or znc or using a 3rd party service like IRCCloud). Issue applies to channels and private conversations.
  • Few high quality apps, especially for mobile devices (IRCCloud app is not entirely free)
  • The lack of a “user is typing” indicator slows down conversations (counter-argument: indicators not always reliable, may become a distraction / put people off writing a reply of their own)
  • Many contributors haven't used irc before, and new tools can be a struggle for even technical users (counter-argument: IRC webapps make IRC easier to use, but it is still more of a challenge than modern alternatives.)
  • Although possible, it is difficult to create hooks into third party services.
  • Usage is dropping on IT circles for maybe a decade now (IRC protocol is on decline)
  • Doesn't do voice, video calls or conferences
  • Lack of modernization for sharing files (Services like Dropbox, Google Drive are not preferable because it fragments the community and if any of these services die, the files are gone forever. The files are not either instantaneously available in the client)
  • Can't show media, like photos, maps, etc. (Support of media is dependent on IRC client)
  • Can't share stuff permanently. (ie, can't host shared media forever)
  • Doesn't support login by email address or phone or external credentials
  • Can't login from multiple clients and share username without magic like nickname aliases

Proposed resolution

Requirements for chat system:

  • Open source
  • Backscroll/offline History
  • User typing indicator
  • RTC (audio/video)
  • Bot integration
  • Mobile support
  • Future integration with d.o/projects

Possible solutions:



1. Create/switch to Matrix

Matrix is an open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers.

  • Pros
    • Open standard/API
    • WebRTC compliant/superset
    • Various ways to connect or integrate
    • Has all the current "features" of IRC + more
    • Integrates with existing IRC servers + channels to facilitate migration or keep usability parity (i.e. support stubborn people who still want to only use IRC).
    • Standardizes user identifiers/authentication (e.g. @username:drupal.org) which would allow for easier discoverability and the ability to initiate chats with other users.
    • Allows for future d.o integration (i.e. web based RTC) and possible per project/issue chat "rooms"
    • No need for "user creation" as this could be tied directly into simply using their current d.o account/authentication.
    • Read their FAQ for more info.
  • Cons
    • Not "IRC"
    • Newer technology?
    • Requires a little bit of setup to create our own "homeserver", but this is rather trivial and well documented. A "homeserver" really only helps to facilitate the storage of data, provide authentication and RTC discoverability; most of which is automatically handled. It's really just a matter of setting up the proper config.

2. Keep existing IRC

  • Pros
    • We currently use it
    • Open standard/protocol
    • Multiple GUI applications
    • Many other FOSS projects use IRC, so contributors to those projects can easily join the Drupal channels
    • Optional user creation, no register user required for use
  • Cons
    • Old - lacks modern features needed
    • No API/automated integration (bots must be manually constructed and hosted somewhere)
    • No history/offline history built-in
    • GUI applications - inconsistent implementations (i.e. what "features" are provided)
    • Optional user creation, required if you want to keep a "consistent" user identifier

3. Do #1 and #2.

Other solutions mentioned - Free/paid services:

  • Matrix.org is another Open Source chat service, locally hosted slack clone / free SASS. Currently has dozens of FOSS servers, clients (most popular client is Riot.im) and integrations, including IRC, GitHub, and much more!
  • Gitter.im Github/Gitlab integration makes this a place for FOSS chat. Has been bought by GitLab and will turn FOSS during summer, to allow people to use it as a locally hosted slack clone. Free service.
  • Slack.com, SAAS. Meets most of the features requirements listed, but does not meet goals related to FOSS/privacy philosophy. May require paid service.
  • Hipchat.com, SASS. It meets most of the features requirements listed. 3rd party integration, but does not meet goals related to FOSS/privacy philosophy. May require paid service.
  • Telegram.me is a WhatsApp clone, with Open Source clients and a proprietary server. Supports channels, groups and private conversations and has many bridges/bots, including for IRC. Since recently, also supports voice calls. Still, it's less feature full than the others. Completely free service.

Other solutions mentioned - Self hosted software:

  • Matrix.org is another Open Source chat service, locally hosted slack clone / free SASS. Currently has dozens of FOSS servers, clients (most popular client is Riot.im) and integrations, including IRC, GitHub, and much more!
  • Rocket.Chat is another chat service, locally hosted slack clone, the most popular of the FOSS kind for big companies and organizations.
  • Mattermost is another Open Source chat service, locally hosted slack clone.
  • Gitter.im Github/Gitlab integration makes this a place for FOSS chat. Has been bought by GitLab and will turn FOSS during summer, to allow people to use it as a locally hosted slack clone.
  • Zulip is another Open Source chat service, locally hosted slack clone.
  • Lets chat, F/OSS. Node+Mongo, meets many of the requirements listed, but not as integrated or used as slack. Also needs to be hosted locally.

Other solutions mentioned - IRC magic:

  • Waartaa is an open-source solution with a responsive web interface based on the MeteorJS library for browser-to-server communication and syncing. It connects to IRC on the back-end, giving users the choice of using the web interface or a traditional IRC client
  • Convos works on top of IRC. F/OSS, has backlog, desktop notifications, content previews.
  • IRCCloud Has a desktop, android and ios app, has all the features above and there are several people using it already.

The why and why not Slack.com

  • Pros
    • Some developers already have Slack app running
    • Has many of the above requirements
    • @todo
  • Cons
    • Closed source/proprietary
    • In it for the money: https://slack.com/pricing
    • "Free" plan is intended for small to medium sized business/teams (Drupal is anything but)
    • Requires users to register
    • Architecturally has several types of limitations since their service is based on "small to medium" sized teams: https://medium.freecodecamp.com/so-yeah-we-tried-slack-and-we-deeply-reg...
    • Prohibitively expensive to get backsroll
    • Does not have all of the above requirements
    • Does not and will not support Open Source Communities
    • Allows users to easily impersonate other users on d.o [comment#233]
    • @todo

Remaining tasks

Poll / survey kindly created by @pwaterz:
https://www.surveymonkey.com/r/XKZPYBC

See results at:
https://www.surveymonkey.com/results/SM-6R9V6KKK8/

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kgoel’s picture

Issue summary: View changes
kgoel’s picture

Issue summary: View changes
Antti J. Salminen’s picture

Personally I really do not want to see this happen. Thank you for the well-thought summary as it already has many of my objections covered. I'd add that IRC being an open protocol with huge amount of open source support means it's extremely flexible.

Making chat participation easy can be achieved building on top of IRC. It's possible to set up all kinds of web-accessible interfaces and even gateway bots between different services so I'd argue things can be improved without a migration to something else.

There are also ways in which these tools like Slack/Hipchat raise the barrier of entry rather than lower it. Most of them, like Slack, require registration. Everyone stays on their own little island that you have to separately register to. With IRC there is no registration and with so many open source projects on Freenode you may well already be set up to just join another channel.

I wasn't convinced by the arguments put forth by the WordPress team at all. The only one that I do think is a good point is about the maintenance overhead.

Regarding the WordPress participation: I think it's too early to assess the impact fully. The claims I've seen about increased participation were also made a pretty short time after the move so I'd like to know what's the latest on that.

YesCT’s picture

Issue summary: View changes

a little bit more issue summary detail. more to be added later tonight.

jaredsmith’s picture

Issue summary: View changes
ricardoamaro’s picture

Issue summary: View changes
YesCT’s picture

Issue summary: View changes

adding some stats, and things to keep in mind about stats.

japerry’s picture

Issue summary: View changes
japerry’s picture

Issue summary: View changes
Antti J. Salminen’s picture

Issue summary: View changes
Antti J. Salminen’s picture

The only source I've been able to find that has claims about WordPress seeing any sort of increase in participation after switching to Slack are these tweets.

Later on in the thread it's said that it's just a guess, but maybe we could get some actual numbers as they were offered.

Antti J. Salminen’s picture

Issue summary: View changes
mfer’s picture

One thing to consider for the tools is that with IRC you can have channels open for numerous projects while tools suck as Slack are focused on a single project. This affects cross project interaction.

Crell’s picture

I find Slack useful for in-group communication. Private groups, company internals, etc.

For a public group that we want to make easy to wander through, IRC all the way.

davidhernandez’s picture

I mostly agree with Crell. I'm not a slack user, so I'm taking a look now. It appears to be invite only. How would we handle that?

Would we make one slack team and then mimic the same channels in it that we have in IRC?

japerry’s picture

Even though I think slack solves most of the issues, personally I don't think we should be specifically using slack. The invite only thing is, well, uninviting. However, there are some open source solutions which we could investigate. (Like lets chat) What would be really cool is having chat tied to the drupal.org account.

Hipchat is another option mentioned, and if Drupal infrastructure is moving towards crowd, we could use that and get user integration for free. While in principle I like the idea of an entirely F/OSS option, it also requires our own infrastructure, which has its own costs. Using something like Hipchat (especially if its free for us) would keep in line with our chat budget, which I think is currently $0 ;)

davidhernandez’s picture

Does anyone know who controls drupal.slack.com or drupal.hipchat.com?

I created drupalcore.slack.com and drupalcore.hipchat.com. Feel free to try to join them and play around.

joshuami’s picture

I'm checking into who created drupal.slack.com. It was not Association staff, but I have reached out to Slack to see if we can transfer that ownership.

I'll do the same for HipChat. Even if we do not go that route, it would be nice if we understood how those channels were being used.

davidhernandez’s picture

One thing we noticed is that slack requires an invite and displays your email address to everyone. So if you want to join it will display it to others. I haven't seen a setting to hide them. We assume there is a better way to handle that since wordpress has direct integration.

Also, Cottser was very upset that his username had to be all lowercase. :P but I imagine spaces would be a problem too.

Tezcatlipoca’s picture

Hi guys... this is a thoughtful discussion. I can see you all are putting a sufficient amount of consideration into the concept of moving on from IRC. Being rigorous is important. But I have to tell you: I think it's a no-brainer. And more I think every day we practice relatively insufficient communications, we fall behind emerging web technologies and also put our community at risk to poaching by other evolving communities and technologies (and let's be honest the only thing that makes us truly special and relevant is the community we have here and through it the work we all put in).

I have a few things to say on this subject. Slack in a uniquely innovative piece of software (to my mind) that satisfies the goals of text-centric communication in a number of elegant ways. And say you don't always want to limit it to text--no one will argue that text is always best method of comm: integration of Google Hangouts for instance, allows for a quick and easy switch to more personal communications--considered all together it's the type of communications system we were promised in sci-fi.

Beyond that it's many other integrations official and community contributed make it ideally suited for so many of the things we do here. We could let each other know what we are currently working on. We could integrate our issue creation and tracking. Github integration could allow us to work and talk together seamlessly--offering an unprecedented ease that would allow us to jump over all the cruft and time sinks and just get more done together! And we wouldn't have to give up the freedom of our self-hosted git repo. Say we just allow pulls and merges to a mirror on github--perhaps the existing one that exists for other reasons (an example demonstrating that people will not sit idly by and allow modern conveniences that make life easier to go unutilized). Then we just merge in the changes. This is typical of the kind of trade-off (or lack of that we would be making in going to Slack).

IRC is a clunky 27-year old protocol having changed little in that time with a stagnating software ecosystem; it can really evolve no further to utilize it on that foundation. #drupal and the sister channels are really great. Now, I hate IRC and describe it overall as "a generally bad place where dreams go and die." That's clear hyperbole, but we all know it's less than ideal and its faults restrict both the people that use it and the communication that goes on there. The reason #drupal is great is for the same reason Drupal is great. We happen to have very many good and invested people. And they are for the most part just bearing IRC, tolerating it. Just because that's how it works, because that is how it has worked.

We have a chance to really grow as a community in quickly moving to a modern communications platform. Slack is fun! My experience is people love to use it--all kinds of different kind of people. It would open us up to a whole new world. None of that can be said with IRC. But with slack, again we don't have to give up the passable solution that's now in use. "slack-irc" a community contributed module/integration could allow us to communicate between the two, the existing IRC channels and the new Slack. And more if people are attached to their clients or dislike Slack as software, Slack provides easy and free access to the Slack and channels through the existing IRC client of choice.

I understand there is a concern that Slack is not open source or decentralized. That is significant. But it is very open in many other ways--in addition to being free. It is highly configurable with a strong API that allows us to build into it nearly any functionality we could want. Even just in the core it's built from the ground up to allow configuration and programmatic improvement allowing us to tailor it to our needs and goals. If you haven't give Slack a fair shot, just try it, because I can talk all day but none of this and much more I am leaving for lengths sake won't be apparent until you've done so. Which is a great segue...

Tezcatlipoca’s picture

This is how I came to find this discussion: I've recently become involved in a number of webdev slacks that are quickly changing a lot in how I work and spend my time. Naturally I sought to find a Drupal specific Slack--official or unofficial. I could not find it. I was so very surprised.

This afternoon, I decided "no longer." I created one called "DruPals" a light-hearted and quickly made up name for something I hoped would be similarly lighthearted community around the Drupal that I love. A few hours and one Drupal site later. I have created the Slack and a site to facilitate and automate invites/registration.

I went to the IRC channels to recruit people late on a Friday evening (not the best time to do so) and I was directed here to read this conversation and make these posts.

So to keep this from getting any longer. I very much hope you'll join me. This doesn't ever have to move further toward the goal of being an official solution. I would be happy if simply I had some Drupal folks to talk to in a fun environment like Slack. But also, if you want to try on Slack as a possible solution to move to, here is an opportunity. Thanks for reading. Hope to hear back from you... maybe in the Slack!

davidhernandez’s picture

One point in favor of Slack is it has built-in IRC integration, which I enabled on drupalcore.slack.com. So far Cottser is the only one who tried to connect over IRC, but it did seem to work. I also added josuami as an owner so he can investigate integrations and other such things. The immediate concerns that are all show stoppers are the invite-only aspect and email addresses being visible to other users. (both may have solutions through drupal.org integration.)

The other thing that would greatly concern me about trying to use Slack for our community is scalability. Just looking at the interface, I see how this can work well for a team, but I don't see how it doesn't become unmanageable with hundreds/thousands of team members.

joshuami’s picture

Issue summary: View changes

Hi all, I had a conversation with Slack support today. They are excited to help us in whatever level of demo or integration is appropriate. To that end, the drupalcore.slack.com account has been changed over to drupal.slack.com so that we at least hold the namespace.

I've also talked with Slack about what scalability and privacy would look like. They do have some sort of public rooms and or community teams planned in their roadmap, but they are still working through those requirements. If we want to provide them with requirements that would make sense for the Drupal community, I'm happy to act as a conduit.

While I'm not convinced just yet that we *should* move to Slack for the community, I do think it provides a lot of great functionality.

I have been quite impressed with its use by Drupal Association staff for internal collaboration and for external collaboration with the community members that are part of the DrupalCon planning. They have been using Slack for planning the DrupalCon programs starting with LA. Drupal Association staff have been using slack since November. Given that we have a good mix of technical and nontechnical employees, Slack has been incredibly easy to implement within our organization. (Far easier than setting non-technical users up with IRC for instance.) That same ease of implementing Slack is not likely to be the case for a community roll out. I share David's concerns about scaling that administrative interface to hundreds of users.

Does anyone have a good sense of how many unique Drupal IRC users exist? I'm curious just for the sake of knowing how big we need to think in considering alternatives to IRC.

In the meantime, at least we own the drupal.slack.com namespace for testing possible integrations.

Mixologic’s picture

Issue summary: View changes

Here's another open source slack clone:
http://www.mattermost.org/

kattekrab’s picture

@joshuami

"Does anyone have a good sense of how many unique Drupal IRC users exist? I'm curious just for the sake of knowing how big we need to think in considering alternatives to IRC."

This might be something we could ask the freenode ops to find out for us?
The biggest channels, #Drupal, #Drupal-Support and #Drupal-Contrib - but there are hundreds of smaller channels, and I know many people aren't on the big channels for various reasons.

japerry’s picture

Telegraph.org is another suggested chat medium.
Gitter works from github.

geerlingguy’s picture

One good point of reference—a reason why you can pry IRC from my cold, dead hands—LimeChat (on 8 different IRC channels with two networks, been running for a few hours today) is using about 30 MB RAM. Slack, with about 10 channels across two 'teams', is using 490 MB RAM.

Lightweight, many of these other solutions are not... that's one major concern as I look at my Dock and now see Adium, LimeChat, Skype, Slack, and HipChat clients all required for different projects. I hate the idea of requiring terabytes of wasted RAM across the Drupal community just so we can get a few more likely-inactive-users signed up for official chat channels.

The sell has to be a lot more compelling than inflating numbers of logged-in users. #ansible generally has 1,000+ users in the room, but only a couple hundred have ever posted much, and far fewer actually use the room for more than 'StackOverflow Instant Q&A' (more like the #drupal-support channel than #drupal or #drupal-contribute, both of which are more community-oriented).

star-szr’s picture

Slack is one alternative that we've been testing off and on it has an IRC gateway.

geerlingguy’s picture

@Cottser - If the IRC gateway is enabled (and works well under load), then that would negate some of my earlier arguments, since I (and others) could continue using IRC clients with Slack.

star-szr’s picture

It's enabled, I tested it, not sure on the load part.

cferthorney’s picture

As a potential work around for the whole invite system that Slack integrates, the Laravel people have created an auto invite system of sorts over at larachat.co, it would suggest that some sort of integration can be rigged together even if someone within the community had to write something from scratch from an integration side of things? (I've not even begun to look at that so don't even know what is or isn't possible with their API's)

Kind regards
Dave

realityloop’s picture

Issue summary: View changes
realityloop’s picture

Issue summary: View changes
lsmith77’s picture

what about talking to irccloud.com about a special deal for drupal related channels to be part of the free package?

fuzzy76’s picture

While I personally love Slack, I really don't feel comfortable with Drupal going all in for it as a recommended communication channel. Do we want to become dependent on a proprietary commercial system?

Pol’s picture

Hi,

I'm also willing to test slack, could you invite me please ?
Here's my email address: pol.dellaiera@gmail.com

Thanks a lot !

kgoel’s picture

I have added "Technical Working Group" tag so someone from the group or group can evaluate if it's possible to replace IRC or not.

Pol’s picture

Issue summary: View changes
rteijeiro’s picture

I think it's a terrible mistake to switch from IRC to a non-FLOSS solution just to "make chatting easier"?. I don't think we are going to solve a problem (if there is a problem) just switching or adding more tools to our daily basis.

I think it's just about culture. There are people that like synchronous communication like chats and there are other people that like asynchronous communications like email.

That's all.

I think we don't need more tools.

fuzzy76’s picture

FWIW, I think Mattermost and "Lets chat" looks like better candidates. Most of the advantages of Slack, running on an open implementation.

chx’s picture

Suppose They Gave A War and Nobody Came.

Sure, somebody (who?) claims X is the new schnizzit and then the community shrugs and continues to use IRC. As mentioned on Drupal SE meta "Drupal communities are a bit balkanized, so often top-tier Drupal contributors are most active in their own local channel, or the project specific channel which interests them most—the maintainers of Drupal Commerce hang out in #drupal-commerce for instance" so you'd need to fight that down one by one. Good luck.

This issue should be won't fixed as it's impossible.

wizonesolutions’s picture

Perhaps Sameroom is worth checking out? https://sameroom.io/open-a-tube

You can open "tubes" to bridge chat platforms. So, in theory, people who like IRC wouldn't have to switch. Haven't tried that combo, but might be worth testing?

wizonesolutions’s picture

Re. @davidhernandez's concern about email, WordPress has set up a USERNAME@chat.wordpress.org cloaked email. That's similar to what we did for Git. So many our auto-inviter can do something similar. This would require setting up an email relay, but if WordPress can handle that, we probably can do. They should probably be distinct from the Git addresses and ONLY work for people who've actually signed up for Slack. And, like WordPress's, it would only actually accept email from Slack's servers (so no one can use them to email people against their will).

Seems like a good solution to that issue. Maybe we can ask them how they did it.

chx’s picture

> This might be something we could ask the freenode ops to find out for us?

I can try asking freenode staff to query how many users are on #drupal* but it might not be something they can (easily) do. Note this is not something the Drupal group contacts can do -- we have very few powers the users don't. Mostly just enough to kick and keep trolls out.

kgoel’s picture

Issue summary: View changes

I have removed "request to join Drupal Slack channel" from the issue summary because it doesn't say contact who. I have received requests for joining slack and I don't have any control over that and I don't know who is moderator/admin for that. Users are mistaking me as moderator since I created this issue. I don't want to be rude to them by not replying and I can't reply to all the emails :)

basic’s picture

Another option, just to throw it out there: https://telegram.org/blog/channels

Telegram has channels now, and clients on almost every platform.

heddn’s picture

https://zulip.org is open source and has clients for many platforms.

Crell’s picture

lsmith's suggestion of contacting irccloud.com seems like the best one yet; still IRC under the hood, but a nice client since that seems to be the biggest gripe people have with IRC. (Other than it not being hipster enough, which I ignore as a criteria.) That's nice and low-effort. Anyone want to give that a shot?

Pol’s picture

+1 crell. I discovered irccloud last week (@drupol on irc).
I bought the subscription right away.
The android client is very good too.
Cant live without it now.

Pol’s picture

That said, Telegram and channels are super good too.

fuzzy76’s picture

Atleast half of the concerns in the issue summary are still valid on irccloud though.

realityloop’s picture

@heddn I tried Zulip today on one of my servers, the desktop client on OSX at least has no way to connect to a private server, also the UX is very confusing (I'd almost say worse than IRC).

It also allows anyone to create private streams which I don't think is a good idea personally.

tim.plunkett’s picture

An article on the React community moving away from Slack: https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to...

tim.plunkett’s picture

Ooh, even better, they posted the research they used to make the decision: http://www.jordanhawker.com/posts/131477030371

Antti J. Salminen’s picture

The concern listed in the summary about IRC lacking scrollback/history doesn't seem like a very strong argument when it's a feature that's easy to have even without bouncers. It would even already be possible via druplicon but has not been enabled for the drupal contribution channels by choice.

Based on the Reactiflux and freeCodeCamp experiences described in the link in #55 Slack seems like it's probably a non-starter...

Solutions that don't get rid of IRC but help with the concerns about the barrier of entry seem like the best to me. Working towards just getting a better Freenode webchat would be ideal in that all the open source projects on the network would benefit but that's probably a pretty challenging way to do this.

elwayman02’s picture

Tim, I'm happy to answer questions about the research I did...thanks for linking it here! I'm pretty happy with Discord right now...the onboarding experience is great and barrier to entry is low.

webchick’s picture

Also there's like barbarians and shit:

Scenic gamer background

I played around with this for a bit and it's very interesting. The fact that you can jump to voice at any time IMO is hugely beneficial, esp. for gnarly technical discussions and/or highly aggressive convos that are going off the rails.

One immediate question I'd have, knowing about various incidents involving gamers on Twitter, is how private is a given Discord server? Are we going to get numbskulls barging in and using l33t sp34k and threatening to beat up women? (IRC is definitely not immune from this problem at all but for whatever reason—probably a crap ton of work on Freenode's side—we've been really lucky with this.) Another one would be, are we impacted if one Halo clan and another Halo clan decide to smack each other around? (We have gone down too when neighbours have been DDOSed on Freenode, OSL, etc. in the past.)

markie’s picture

FWIW: Here's the link to the WP intro page. https://make.wordpress.org/chat/.

wizonesolutions’s picture

I predict WordPress is going to hit the same limitation as React did pretty soon.

Discord's probably worth looking at. It's not Slack, but IRC isn't Slack either. The throwaway joins are a pretty cool feature. Much less of a barrier than Slack.

Does Discord keep email addresses private? That would mean we wouldn't have to run a purpose-built relay to mask them like WordPress does for Slack.

realityloop’s picture

@wizonesolutions

Yes with Discord email is hidden, even to the server owner..

marcvangend’s picture

I just came across this post https://drewdevault.com/2015/11/01/Please-stop-using-slack.html which lists a couple of reasons why you should not use Slack for FOSS projects, and names irccloud as the best alternative.

Derimagia’s picture

Another benefit of slack is that they bought Screenhero a few months back and are working to integrate it in. I think this would be a big plus for cooperation.

https://slack.com/screenhero
http://blog.screenhero.com/post/109337923751/screenhero-joins-slack

Edit: I didn't see the article about React moving away from slack. That's a real shame. My point is moot.

japerry’s picture

I just came across this post https://drewdevault.com/2015/11/01/Please-stop-using-slack.html which lists a couple of reasons why you should not use Slack for FOSS projects, and names irccloud as the best alternative.

IRCcloud costs money. Its a non-starter for 'removing the barriers' to entry. Contributors shouldn't (and won't) be expected to pay money just to communicate.

heddn’s picture

IRC Cloud has a free option. And for most people, that is fine. They don't need to stay online 24/7. Which, from what I can tell, is the only benefit from paying 5/month.

star-szr’s picture

But then we lose the asynchronous benefit right?

fuzzy76’s picture

@heddn That solution won't satisfy even half of the concerns mentioned in the issue summary.

heddn’s picture

Status: Active » Reviewed & tested by the community

Here's the thing, IRC Cloud by itself isn't the solution. I think that IRC is the solution. Because it is open source and has multiple clients. Not all of which are terrible. If the barrier to entry into IRC is its complexities, solutions are being developed to overcome it. IRC Cloud is the best example I know of. If you want a proprietary solution i.e. Slack, then you can, if you want connect it to IRC. Flexibility for our diverse community is critical. The biggest knock against IRC has been its high entry-bar. And for the past 7 months, we've not found any better solution than IRC.

So, if the entry-bar is lowered via solutions like IRC Cloud, what are feasible/reasonable solutions?

I'm not convinced we have consensus yet, or ever will have consensus. So, unless we want this issue to just be a breeding ground for rants, I'm going to take the tentative step and mark this RTBC. IRC works. It isn't ideal. But another solution doesn't exist. We can (and probably will) revisit this decision again in another 6 or 18 months. But until then, let's move on with other things.

Or maybe I'm wrong and I haven't summarized the rhetoric. Maybe there is a solution that has surfaced above or will surface by someone else in the next few days. In that case, feel free to move this back to "needs review".

star-szr’s picture

I don't think this is accurate:

If you want a proprietary solution i.e. Slack, then you can, if you want connect it to IRC.

Slack provides an IRC gateway but I don't think you can connect Slack to Freenode. But maybe I misinterpreted this :)

fuzzy76’s picture

@heddn This issue is still about the concerns people have voiced with IRC, as listed in the summary on top. Adding IRC Cloud on top as a "preferred" client still won't change the list of issues much (15% of them maybe).

And @cottser is right, Slack can't connect to IRC but IRC-clients can connect to Slack. Most of the third-party solutions suggested here (including Slack) has a lot of features that IRC-servers doesn't support.

ztl8702’s picture

@cottser You can "connect" Slack to Freenode by using a bot to forward messages between those two systems.

Antti J. Salminen’s picture

Wanted to expand on some of the concerns I see with moving to one of the mentioned services. The Hacker news discussion of the article that @marcvangend mentioned in #62 has more on some of these.

Concerns with choosing one of these services

Here are some concerns I'd like to raise about going with any system that is hosted, closed source and a walled garden - be it Slack, Discord or something else. These services are completely under the control of the company that provides them. An example of this biting someone that just happened is that while Slack does list unlimited team size as a feature, it turned out there actually were limits for the Reactiflux community at least. The Bitkeeper episode in the history of Linux kernel development is another cautionary tale of what can happen when you don't consider these risks.

These companies can pivot, they can go out of business or they can come up with disruptive ways to monetize their product only after building a gigantic userbase. Possibly even worse, they can also fail to do so (see PlugDJ). Discord for example is a free-for-all service that seems to only have very vague idea of how they're ever going to make money. It would be wise to assume the pricing won't stay fixed and something like Slack deciding to charge everyone per-user would be problematic for Drupal to put it mildly.

Things like IRC/XMPP bridges can also go away later on in the life of these products. Once again the examples are many but just a few are Twitter getting rid of RSS, Tapatalk closing their API and Google Talk disabling federation with other Jabber servers.

The services often lack any support for Linux (let alone BSD). I think in an open source community some thought should be given to that. It's likely that more people than on average are on those platforms. Things like IRC bridges and web interfaces become the only option then and the user experience they offer is often second class. The option to use a pastebin looks very nice compared to the prospect of not seeing the pasted code in a clean way over a the bridge.

Issues with Slack

Besides the huge issue that Slack apparently doesn't support communities of this size as Reactiflux found out the hard way, I've seen some other limitations being mentioned for it:

  • The IRC bridge does not render many of the features correctly
  • Free Slack has a backlog limit of 10,000 messages which is hit pretty fast with a big community

Issues with Discord

It doesn't sound like they have a real plan for how they'll make money yet and their target audience is gamers, not software developers. This could mean they end up prioritizing features that are of no use to Drupal or even doing something that doesn't work for Drupal at all.

Some features they're lacking:

  • No IRC bridge
  • No search

Would switching from IRC actually hurt participation?

The Freenode network has 90,000-100,000 active users. Most of these are very likely to be interested in open source software. Making it harder to join for this substantial pool of people with relevant interests sounds like raising the barriers of contributing instead of lowering them. They are now just a /join away but won't probably start using 3 different services if WP is on Slack, Drupal is on Discord and PHP stays on IRC.

fuzzy76’s picture

Issue summary: View changes

I totally agree with the concerns about commercial services. We should not be tied to the survival of companies with changing priorities and business plans.

But this is not an issue with the self-hosted open-source solutions. After a brief research round, the only one of them that seem to support an open protocol for third party clients is Let's chat which has XMPP support. That would let people use any client that support XMPP (quite a few IRC clients do), and bitlbee if people really want a bridge.

I also wanted to add that lack of Linux support is a pretty moot argument for something that's primarily a webchat. If your browser can run it, you are supported. The apps aren't much more than a webview any way.

marcvangend’s picture

Issue summary: View changes

Thanks Antti.
+1 for mentioning that moving away from IRC may raise the barrier for people from other FOSS communities who are already on IRC. I'm adding a list of arguments in favour of IRC to the issue summary, feel free to expand it.

realityloop’s picture

@fuzzy76 Main potential issue I see with Let's Chat is that they say its for "Small Teams", it seems like mattermost may be the best long term option, but it's still not perfect.

mlhess’s picture

This comment is in full HTML and has some IRC cloud embeds in it.

I talked to irccloud folks today. They are willing to work something out for us.

By default, they have buttons that we could add to our IRC page.

They have an inline javascript embed, which I have not put here, but we could use if we wanted to as well.

That will require a email and email confirmation before allowing a user in. However, they are open to doing an SSO with Drupal.

So the workflow would be something like
Non logged in users:
1) go to the IRC page on d.o see warning message that D.O will share your email address with IRC cloud
2) see listing of all channels
3) choose which ones you want to join
4) on IRC cloud, provide email address
5) check your email account and confirm.
6) Your on IRC in those channels

Authenticated users
1) Go to IRC page on D.O
2) See listing of all channels
3) choose the ones you want to join
4) You're on IRC in those channels

fuzzy76’s picture

  • Asynchronous conversation isn’t realistic short of setting up your own proxy.
  • Writing and maintaining tools are painful.
  • Mobile and native apps are mostly terrible.
  • The lack of “user is typing” slows down conversations.
  • Too much overhead to add new channels for ongoing projects.
  • Many channels don’t have ownership or moderation
  • Many contributors aren’t technical, and IRC can be a struggle for even technical users.
  • Although possible, it is difficult to create hooks into third party services. IE: creating a hangout in slack: /hangout.
  • No integration with our projects. Channels are made independently from the project
  • IRC is old
  • there is no scroll back/history
  • to get history, some people set up bouncers (such as bip or znc) or use a service (but that increases the barrier) like IRCCloud
  • IRC is difficult to use, for example
  • Setting up an IRC client is complicated
  • Depending on the client, doing common tasks such as getting a list of channels is complicated
  • Limited choices for some operating systems

That fixes 6 out of 16 problems listed in the issue. What about the rest?

If we do decide there is no better option than staying on IRC for now, I guess the IRCCloud integration is better than nothing. But we still need to acknowledge that it means leaving the rest of the problems hanging around.

mlhess’s picture

Too much overhead to add new channels for ongoing projects.

It is REALLY easy to add an IRC channel.

Many channels don’t have ownership or moderation

This would be true in any service. It takes people to own a channel.

Many contributors aren’t technical, and IRC can be a struggle for even technical users

This would be resolved by irccloud.

IRC is old

What does this mean?

Depending on the client, doing common tasks such as getting a list of channels is complicated

I think this is solved.

Many of the other items up there are not solved by any solution but rather work on top of a solution. I am also not saying that IRC cloud should or is the solution, but it solves many of the issues above, and could be implemented without many changes or much work.

Maybe that we need a solution for folks getting help that includes realtime, forums, and communities.

joelpittet’s picture

Issue summary: View changes

Removing 'IRC is old', it's not a valid reason for anything. Also may be a benefit because it is also fairly stable, tried tested and true;)

killes@www.drop.org’s picture

I don't know if anybody cares but I won't use software that's a) run as SASS by a potentially unreliable 3rd party or b) not Open Source within the context of communication of an Open Source project. That feels just wrong to me.

IRC just works fine for me.

But then: the only channel I really use nowadays is #drupal-security. Assuming that stays on IRC, the rest can move to #drupal-hipster elsewhere.

heddn’s picture

re #81: that's fine. Using something like irccloud gives folks like you that flexibility. But it is still IRC, so it also gives folks who want to use Adium, LimeChat, HexChat, Pidgen, etc their choice of options too. But the positive to using irccloud is that for folks who do not have your qualms and just want to connect to the larger community, we can lower the entry bar. It would give another entry into our community. And more entries is usually a good thing.

killes@www.drop.org’s picture

I don't share the belief that lowering the barrier to entry is a good idea.

irccloud.com probably is one of those "potentially unreliable 3rd party providers".

You of course are free to use it.

joelpittet’s picture

@killes@www.drop.org I tried to join #drupal-hipster yesterday, I was the only one there... I'm guess it worked? :P

greggles’s picture

Issue summary: View changes

I've update the issue summary a bit.

I restated a few things and separated out some items that seem like general problems that are not specific to irc.

I removed "irc is difficult to use, for example". That seems vague and redundant with some of the others and rather subjective. I find irc quite easy to use compared to slack, especially for the number of rooms that I join. When I've tried slack and had more than ~5 conversations open it became hard for me to understand which conversations had unread messages.

I added a note asking for other examples of third-party integrations that are useful other than "/hangout" ? The ability to quickly generate a hangout url feels like a pretty weak feature of these kinds of tools.

I reordered the list to group together similar issues. A lot of these feel like the same problem said in a different way which makes irc seem worse than it is. I didn't delete all of the duplicates just yet, but I think a few more could be deleted/consolidated.

I also added to the subjective part about proposed solutions to indicate that while some of the SAAS solutions like Slack solve many of the feature-requirements they do not solve some of the privacy requirements and philosophy goals. http://www.theverge.com/2014/11/24/7255199/slack-alters-privacy-policy-t... is an example of a privacy concern related to slack, for example. I'm not sure that specific change would be relevant for our organization, but the fact that they can make that kind of change in the manner a typical corporation does (without user feedback until after that event) makes me rather wary.

I think that irccloud is pretty awesome for some use cases (I've used it a bit and didn't pay for it).

I use a mix of hipchat, slack, and irc for work. I do not think that a solution like hipchat or slack would be a good solution for the Drupal project in general. They are focused on solving different problems for different communities. irc, and freenode specifically, is directly focused on serving communities like ours so they are more likely to have philosophies and ideals that match ours.

fuzzy76’s picture

First of all, I just need to congratulate @joelpittet for being able to say that he hang out in #drupal-hipster before it was cool. :)

On a more productive note, there is also http://shout-irc.com/ which is a sort of "open source, selfhosted IRCCloud". I have no idea if it is scalable enough for Drupal to host it, but it seemed relevant here. It does have multiple user support.

japerry’s picture

Issue summary: View changes

Added Zulip, another self-hosted option. Also added that the DA, in our discussions so far, has been to not want to host chat internally.

greggles’s picture

I'm not sure what "self hosted" means in this context. Is our current irc self-hosted? Can you expand on that a bit?

fuzzy76’s picture

I guess you asked jasperry, but I think both he and I mean chat clients that uses a backend running on d.o infrastructure in order to provide a persistent connection and a unified user experience. In that regard, the current IRC is not "hosted" at all (it leaves the client and connection maintenance up to each user, which I guess is part of the problem).

greggles’s picture

So maybe another way to say that is that it shouldn't increase the burden on the Drupal project (DA, infra team, etc.)?

fuzzy76’s picture

In that case, a lot of the proposed solutions are off the table. As far as I can tell our main choices would then be:

  • A commercial / proprietary solution like Slack or Discord. The downside is that it would leave us at the peril of a company.
  • IRC with a commercial / proprietary frontend to make it easier for beginners. The downside is that it's still IRC with all its shortcomings (detailed in the summary).
  • Switch to another open protocol (I guess Jabber is the only real candidate?). Just realized this hasn't been mentioned. I guess it's just... not very sexy.
kattekrab’s picture

personally... I kind of don't understand why folk find IRC so much harder to use than Slack. But I'm willing to accept that's my shortcoming.

What I do find odd - is that there doesn't seem to be an IRC client that has stepped up to the challenge posed by Slack. Or have I just not looked hard enough? I think Slack is definitely innovating in the real time chat space. It's slick and user friendly, and has some nice features not found in IRC.

But I share all the concerns raised about it being non-foss and in-appropriate for an open source project.

@greggles - awesome work on synthesising and refining. Thank you!

greggles’s picture

Issue summary: View changes

Thanks Kattekrab :)

As promised in #85 I went through again and consolidated items that were redundant.

basic’s picture

I'm writing this with my own personal biases in mind:

My irc/znc bouncer box died over the weekend and prompted me to set up irccloud in the interim so I could get back to #drupal-infrastructure and my other IRC channels. After using it for the last few days, I don't think I will be switching back to znc any time soon.

What I do find odd - is that there doesn't seem to be an IRC client that has stepped up to the challenge posed by Slack. Or have I just not looked hard enough? I think Slack is definitely innovating in the real time chat space. It's slick and user friendly, and has some nice features not found in IRC.

@kattekrab -- irccloud is nearly there, the only thing missing is an officially supported desktop application. There is an unofficial electron app that is decent enough.

The irccloud interface is nice, and implements many of the "hip" features (inline images, :emoticons:, automatic pastebin, etc.), and usability improvements (async communication, web/ios/android/(unofficial desktop) apps, etc.). It also changes nothing about the underlying irc channels and configuration for those already happy with znc/irssi/textual/etc.

Third party services integration is something we rely on heavily in #drupal-infrastructure and is solved by running irc bots. Druplicon, drupalmon, jenkins, manatee, etc. There likely exists an irc bot for the integration(s) we are lacking.

The only remaining issues (#77 addressed my primary concern) with using irccloud as the solution are the lack of "user is typing..." functionality, and lack of built in search functionality. That said, with all of the discussion and potential solutions discussed this far, it seems like irccloud provides the most benefits while leaving the legacy intact.

heddn’s picture

+1 #94. That's what I've found since my computer died and I had to quickly replace it with another. IRC Cloud was just easy. And it still gives us IRC; so folks that want to use their client choice can. That is the beauty of IRC. It meets the most people where they are at currently, while still giving folks the chance to get some of the benefits of other softwares. I'm specifically thinking of all those capabilities you outlined in #94 that are similar to Slack. In the open world of FOSS, you are going to find it hard to find something so liberating as IRC. And the comments that it is so it is "old school" and "too hard" and "it is blocked at my place of work", do have options. And IRC Cloud isn't the only option. It is just the one I'm most familiar.

So, enough of that. What is next for this issue? Looking over the issue summary again, what are the outstanding items and next steps?

I'd propose as a next step that we just stick with IRC, because nothing better has offered itself up to us. I suggested that also in #68, so I'll let someone else take the bold step and decide where we go from here.

theamoeba’s picture

Issue summary: View changes
Gabriel Engel’s picture

Hi there, I am Gabriel Engel, the founder of Rocket.Chat

We'd love to to host a Rocket.Chat server for you for free.

I believe this would be the best possible option here. You'd support another free open source project and remain free to export your data move anywhere, either to host
Rocket.Chat yourself where ever you like, or move to another solution completely.

If you like to give it a goal with our cloud, please just complete the form at https://rocket.chat/deploy

You will have your server running in a few seconds, and you can get the links to our iOS, Android, OS X, Linux and Windows clients from our website. They are all open source projects too.

Please ping me if you have any questions!

realityloop’s picture

I know that Gitlab's roadmap is to deprecate mattermost in favor of Rocket Chat

greggles’s picture

@Gabriel Engel - thanks for the offer. One thing that I wonder about is https://www.quora.com/unanswered/How-does-Rocket-chat-make-money Can the Drupal community rely that Rocket.Chat will still exist? It would also be good to know how Rocket.Chat might handle some of our existing needs like being able to have private rooms and moderate (i.e. kick) people.

fuzzy76’s picture

Just want to mention that https://matrix.org/ seems to be a really promising open protocol / network which solves a lot of problems in one go (HTTP-based, federated and allows bridging to other protocols - Freenode is already available there). I don't really think it's mature enough for Drupal to consider yet, but personally I'm putting it on the top of my list of technologies to try out.

heddn’s picture

Status: Needs review » Reviewed & tested by the community

I'm going to mark this RTBC and suggest that the next steps are:

  1. For now, we are sticking with IRC.
  2. Create a new handbook page for suggested IRC Clients. This list should include web, fat client and mobile apps. Link to this new page from the various IRC pages.
heddn’s picture

Marko B’s picture

Lets not play this game again and again. Like drupal 7 and drupal 8 and then we moved to full OOP anyway, just waist of time and resources slowing us down.
Do you need more data then this? https://www.google.hr/trends/explore#q=irc
Do you want to attract new people, young people who never heard of IRC and will run away from it when they see it, finding drupal just old tech.
We will again be late because some people don't want to change and we will be on loss because of it.

mr.ashishjain’s picture

What a fantastic conversation I came across while trying to get my hands on IRC [after procrastinating it for almost a year]. Thats the beauty of community, its exactly like "Democracy" where everybody is heard and interests are protected/respected.

I must admit oldage tech IRC is a push away for new joinees. Laravel using Slack too. That shows the evolving tech world is embracing new technological advancements on how they communicate rather than sticking to the age old tech. If we've options, why not?

We use Slack in our organization, but talking about the community, I think we do not need a commercial entity here, but open source, so 2 options seem best to me: Mattersmost and Letschat.

How about starting a voting?

larowlan’s picture

kevinquillen’s picture

Slack is the new hot, but there is no guarantee it will still be running 3-5 years from now. IRC will likely always be around.

Also, consider from that article:

"A few weeks ago, Reactiflux reached 7,500 members on Slack. Shortly after, Slack decided we were too big and disabled invites. There was no way for new users to join. Many of us were sad and upset. We loved Slack. Our community was built around it."

So yeah, there is no guarantee some suit at Slack wouldn't ever be like "hey, there's 45,000+++ Drupal users in the community channels! Cut it off and make them pay $7 a month per person".

Ryver, Mattermost and other Slack clones will have a life half as long as Slack.

Despite my hangups with IRC, its the best fit for anyone, anywhere, on any machine. Doesn't look as nice as the other options, but it doesn't need to, either.

mpdonadio’s picture

This is likely something that we will never have true consensus on, but I am with the crowd that despite its shortcomings, IRC is ubiquitous and works well for the community.

Perhaps, the best followup to this is an issue to explore if there are additions to Druplicon (http://druplicon.info/ and https://www.drupal.org/project/bot) that could improve the IRC experience for people?

andypost’s picture

+1 to stay on IRC

japerry’s picture

japerry’s picture

Status: Reviewed & tested by the community » Active

Similar to the github, forums, or other services, slack is already becoming pervasive within the drupal community. ( http://drupalslack.herokuapp.com/ )

Let me elaborate a little on the 'self-hosted' problem: Chat is not an easy infrastructure item, especially when it comes to scale (over 100 simultaneous users). We've been lucky in that freenode hosts our IRC channels, meaning the Association doesn't have to spend any money on chat.

If its a requirement that we cannot self-host chat, it means we're relying on a third party to not only be able to host us now, but also scale as we grow adoption of the platform. My main worry with slack is that its been proven not to scale, with many large communities regretting the decision to switch.

However, open source may not be the solution here either. Can Rocket chat serve 30,000 users? If we're using a SaaS solution, the open vs closed debate is less important IMHO.

kevinquillen’s picture

slack is already becoming pervasive within the drupal community.

Was pretty dead when I was in earlier in the week; and as you said, Slack does not scale.

What is the main motivation to making the community shift chat protocol/platform? User engagement won't be solved by the software. Is the perception that IRC is scary or hard to use? I'm playing devils advocate.

Crell’s picture

Kevin: Honestly I think it's mostly "IRC is scary and hard to use". "Newbies don't know what IRC is, they use WhatsApp". Or whatever. Secondarily, it doesn't have emoji. (Whether that's a bug or a feature is rather subjective; I consider it a feature.)

Personally I see no significant issue with IRC that isn't solved by

1) sticking an IRC web client on a web page somewhere
2) Pointing people at IRCCloud

(At least none that don't exist in any semi-real-time text medium by definition.)

Honestly, we don't even have to tell people that they're using IRC. They're using "Drupal chat", at http://www.drupal.org/chat. Which just so happens to be one of a hundred web clients for IRC that is setup to talk to Freenode. (Or something similarly smoothed over.) Yeah, telling people to go get mIRC or Colloquy isn't nice, but that's not an issue of IRC itself.

Gábor Hojtsy’s picture

I am a happy customer of irccloud. The reason I started paying after years using IRC with various clients is my internet was bad for a while. It kept throwing me off the channels and it was very hard to hold a conversation. I needed a bot for me so I can read things from the time I was offline. Instead of spending time on trying to set it up myself (which we cannot ask people to do), I started paying for my own good (which we cannot ask people to do either). It was an extra benefit that irccloud comes with a mobile client as well that works relatively well. One definitely great thing about chats other than IRC is that you have a scrollback by default and your presence is much less connection-bound.

Pol’s picture

+1 to stay on IRC but as Crell said, pointing people to IRCCloud or something user friendly would be great.

fuzzy76’s picture

http://webchat.freenode.net even has a nice embed option (even though it lacks the persistent connections of IRCCloud).

dqd’s picture

Let me keep out the IRC pro/con part because, IMHO, I think it is too early to let this pro/con decide here on a much broader asked question to discuss, in a long term. This awesome article and carefully written questionaire is about thinking outside the box, so to simply vote for staying with IRC is contra productive. First, we should take a deeper look into ALL alternatives. Don't get me wrong, I am an officially IRC and terminal chat (irssi) advocate for the most and if it finally comes to the conclusion that IRC is still THE SHIT, I am the first applauding. But that should not be the point here yet, first things first. Not without discussing all opportunities and newer developments carefully. What if we look around and find a combination of both? Who knows? Today all is possible. When SASS came nobody thought of LESS and when LESS was there, nobody thought of that SASS would come back so fast. Today is different then the time when IRC was born. If it would be possible to combine mattermost users and IRC users in the same channel, e.g., well ... I would immediately sign it!

BTW: for the Slack vs mattermost supporters, here is an interesting read: http://www.mattermost.org/what-slack-might-learn-from-its-open-source-al...

And BTW (2): What did I sad some lines above about IRC combined in ... Mattermost v1.1: Now connects to IRC, as well as your in-house applications

Apart from that I certainly would underline the last paragraph from here #107 which isn't against a combination of anything ...

Last but not least: It is actually no *decision* needed, it is just a question of how to improve the experience without leaving IRC, since there are already options to get best of both worlds.

fuzzy76’s picture

Sorry to say, but bridging through a single bot connected to IRC is close to useless for doing actual discussions across networks. The absolute minimum for a bridge should be that everyone sees all users as a user, not seeing half the channel hidden behind a bot. If not, you're ruining nick lists, presence notifications, autocompletion, private messages etc.

Matrix already bridges the entire Freenode network with real clients, and is actually the only one I've seen that accomplishes this. I guess this is because their bridge is linked into the Freenode network the same way a regular IRC server is.

I use this daily. There is also an option for doing it the other way around, allowing IRC clients to connect to a Matrix server using PTO.im.

freelock’s picture

+1 for Matrix.org -- it's an excellent system, far more open than Slack, can be set up with guest access and public history, is already bridged to Freenode (I'm in #drupal and #drupal-migrate right now via Matrix), the bridge shows actual users on both sides, it meets/exceeds all the other desired improvements over IRC. There are great mobile clients and a fast-growing ecosystem.

We also use it heavily as the backbone for DevOps on our Drupal sites. It can be entirely self-hosted, people from multiple servers can interact seamlessly across any number of rooms, etc.

To check it out, you can join the #drupal Freenode room by going here: https://vector.im/beta/#/room/#freenode_#drupal:matrix.org, and creating an account (Freenode-bridged rooms are not configured to allow guest access or history by default).

Best thing about this is that people can continue using IRC if they prefer, and won't miss out!

dqd’s picture

Well, maybe you both misread my post, but that was actually exactly what I was after by mentioning other options. Maybe you misunderstood that I had no preference here persé, but simply took some fast picked examples out of the web only to point to the same issue behind like you: that both combined is possible and no decision against IRC is needed. But maybe you both are referring to other posts before me, then please use #Nr. references to declare that. Otherwise the reader assumes you reply to your predecessor in the queue.

YesCT’s picture

Issue tags: +IRC, +slack
lpalgarvio’s picture

Telegram - https://telegram.org/
Centralized, clients opensource, server closed
Can create channels and groups, with join link and supports bots.
Has webclient and mobile apps.

Bridge IRC to Telegram:
https://github.com/FruitieX/teleirc
https://github.com/RITlug/teleirc

Mattermost also supports bots, has mobile apps, server and webclient, integrates with Redmine, Kanboard, Jenkins, GitLab, GitHub (service) and more.

Bridge IRC to Mattermost:
https://www.mattermost.org/mattermost-v1-1-open-source-slack-compatible-...

Rocket also supports bots, has mobile apps, server and webclient, integrates with GitLab, GitHub (service), Telegram and more.

Bridge IRC to Rocket?:
https://github.com/RocketChat/Rocket.Chat.Federation

lpalgarvio’s picture

Hey,

For our Portuguese Community ("Drupal Portugal"), we are currently using with great success a bridge between IRC and Telegram with the opensource project FruitieX/teleirc deployed in a VM.
We have a bot and a channel on IRC and on Telegram.
Online for about 10 days now.

IRC: #drupal-pt
Telegram: https://telegram.me/drupalportugal
The bot is named Druplbot and can map as many IRC channels <-> Telegram groups as needed.

https://github.com/FruitieX/teleirc

We are looking into additional synchronizations to Hangouts and/or other protocols and considering additional tools.

lpalgarvio’s picture

Issue tags: +Telegram
lpalgarvio’s picture

Slack doesn't seem to support per Channel admins.

With that in mind, I think you can cross out entirely the Slack solution as communities need some independence.

freelock’s picture

-1 for Slack... a closed-source SaaS is not a good fit for an open source project.

There's not really any decision needed to use Matrix -- I'm using it now, in several #drupal rooms. They just launched the main web app under a shiny new brand -- http://riot.im, and it has most of what Slack does, but is already integrated to any Freenode IRC room you want to join.

While the bridge is hosted, the code running the integration is fully open source and published on github, and anyone can run their own copy of the bridge. I run my own Matrix server, and in other chat rooms where a substantial number of participants had switched over to Matrix, we were largely unaffected by the recent Freenode DDoS netsplit issues...

Compared to Slack, aside from the ability to easily self-host and federate transparently, there is no limit to the history that may be kept (Slack has a 10,000 message limit before you have to upgrade to a paid plan), we can open rooms to guest access, and the bridge is far more transparent/less intrusive on the IRC side. The main current downsides is lack of IRC presence (this is available if you run your own bridge, but caused too big a performance hit on Matrix.org so it's disabled -- the issue is that on the Matrix side you can't see whether an IRC user is in the room or not), and a few missing shiny widgets that Slack has (such as reactions, and more bot integrations already written).

See https://riot.im/app/?#/room/#freenode_#drupal:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-migrate:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-commerce:matrix.org for some examples (you do need to log into Matrix somewhere to be able to join Freenode-bridged rooms).

Plus decent Android/IOS clients... And a Weechat plugin if shell apps are your thing. Not to mention, the web app has shiny new e2e encryption now getting a security audit...

I encourage everyone to try out riot.im -- it makes IRC modern, useful, and fun again, and it doesn't move the conversation into a closed silo.

freelock’s picture

P.S. Oh yes, Riot.im does have emoji...

But using them breaks Druplicon!

willwh’s picture

Thanks freelock, I hadn't seen riot.im before :)

I've been using this for a while as my self-hosted IRC: https://github.com/thelounge/lounge, although I couldn't live without database logging, so I made a PR; https://github.com/thelounge/lounge/pull/506. I really can't say good bye to IRC completely, it has been a part of my life for such a long time!

freelock’s picture

willwh: I just checked out the Lounge demo, and I think you'd really like Matrix/Riot... the web client has a similar layout, but adds rich text/markdown, drag-and-drop images, a files tab, automatic pastebin across the IRC bridge, searchable history, all of your visible history available on any device, and even voice/video calling. All without disrupting the existing IRC channel. And you can join any channel on Freenode, Mozilla, OFTC, Snoonet, with more networks getting bridged regularly...

Antti J. Salminen’s picture

Another feature that Slack is missing which might be important to some people when we're talking about freely accessible chat channels is being able to ignore users.

Unfortunately there seems to be some fragmentation occurring now even with no decision made to officially move as some Drupal Slack teams have popped up:
https://www.drupal.org/node/2798167

NWOM’s picture

+1 for Discord. Even though this thread has concluded with IRC being the chosen option to stick with, I hope that the decision is re-evaluated due to the fact that it will inevitably cause fragmentation.

Programs like Discord and Slack provide much more than IRC offers these days. It also allows potential collaboration, and even job opportunities.

The best example is #drupal-support. A person that has a drupal site would be able click an invite link, have it open in his browser, ask his support question, and then get invited to a call to discuss his problem. It would also allow a tighter integration of different rooms (drupal support, drupal development, etc).

I hope the decision is re-evaluated, at least as far as #drupal-support is concerned.

kevinquillen’s picture

Slack can and will change its business model to suit its needs eventually. I wouldn't expect the free tier to be so lax on "unlimited users" forever. That's my opinion on jumping to a platform no one can control. The pricing models are not cheap either. The issue is if you offloaded the entire community to Slack, and 2-3 years later Slack yanks the free tier or restricts it further, or even, Slack closes up shop. Now everyone is orphaned and has to migrate back to IRC.

webchick’s picture

Well... then we get superior communication channels for 2-3 years, until which time we move to the same platform that everyone else adopts as the alternative. Oh well. :)

Antti J. Salminen’s picture

It seems like Slack is not a great option unless some kind of special treatment is arranged anyway. As previously mentioned here, even right now the free tier of Slack has some serious limitations when considering it for a community the size of Drupal such as the 10,000 message limit for history. You might even get kicked out if they deem your usage too heavy duty as happened to the Reactiflux people for example. I understand their plans for nonprofits also have some issues even for communities much smaller than Drupal's.

kevinquillen’s picture

Yep, that's what I was alluding to. "Unlimited free users" isn't really unlimited, just look at Reactiflux.

"A few weeks ago, Reactiflux reached 7,500 members on Slack. Shortly after, Slack decided we were too big and disabled invites. There was no way for new users to join. Many of us were sad and upset. We loved Slack. Our community was built around it.

We reached out to Slack several times, but their decision was firm. Our large community caused performance issues. Slack wants to focus on building a great product for teams, not necessarily large open communities. Losing focus and building for too many use cases always leads to product bloat, and eventually a decrease in quality."

https://facebook.github.io/react/blog/2015/10/19/reactiflux-is-moving-to...

klukacin’s picture

I've just checked all above and more chat-like solutions found currently on web. One of priorities I have in my company is use open source where possible use saas open source solutions if available and that's because our main priority is Drupal development and if I lose resources to maintain my own servers for anything that's not Drupal and even more for anything that's not in like PHP world it's just waste of resources for me. And also we like and use feature/customisation right tools like JIRA (I still havent found alternative for that where I don't have to compromise and have all needed features).

Also I do like altruism like telegram has or, hm, if I remember correctly google has/had also ... but I had to dismiss google photos as they changed important feature like the way share works. So sometimes I have to use proprietary hardware and software (did you know there is almost no open source CPUs! that we can build community upon).

So I vote for rocket.chat!

  • open source server
  • open source client
  • they offer saas hosting for us
  • looks like it has most (very) advanced apps for all platforms
  • looks nice
  • have many features

One feature in development we need to add or support is IRC connector, but that shouldn't be a problem if community decides to go this route. Also testing/beta are advisable ;)

freelock’s picture

@klukacin all your reasons apply to Matrix/Riot, as well. But the best part is, there's no migration work necessary, you can just go to https://matrix.to/#/#freenode_#drupal:matrix.org, use the Riot link, create an account and log in, and you're in #drupal. You can also join any other existing IRC chat on Freenode this way.

- open source server (Synapse)
- open source client (Riot Web, Riot Android, Riot IOS, Weechat, nachat, Quaternion, others)
- they offer saas hosting for us (free accounts on matrix.org server)
- looks like it has most (very) advanced apps for all platforms (markdown support, drag-and-drop file transfer, inline images, animated gifs, end-to-end encryption available, emoji picker, rich text editor, built-in duck-duck-go searching, unlimited history, history search, notification settings, email notifications, invite by email)
- looks nice
- have many features

For Matrix/Riot, there's a lot more:

- Matrix.org hosts the Freenode bridge for us, but that is open source too and anyone can run their own
- 100% compatible with current IRC rooms, automatically shortens long text and provides a link for IRC, automatically embeds links to uploaded files/images on IRC -- if you use Riot you get a much better UX but can work very well with users who choose to stay on IRC
- Servers are federated, meaning those who want to run their own can, and those who just want an account on Matrix.org can do that, and everybody can participate in the same room
- Matrix can also bridge to Slack rooms, and join conversations happening on different chat platforms

Rocketchat seems like a decent solution, but it's no comparison to Matrix for getting started. The best part is, you can use it today, nobody needs to make any decisions here -- just create an account and chat with everyone who is happy where they are!

ekes’s picture

For Matrix rooms - and they are now being made, and used, for Drupal. It makes sense to create them as Native Matrix rooms and then bridge them to IRC or/and where ever else it might be desired. You do then need the permission of someone with Ops for this however (unlike direct #freenode_#room channels).

This way you can add Matrix room administrators, unlike straight bridges to IRC. This means you can decide about how public they are, and how much logs people see and so forth.

So you can make a room accessible even for users who have not registered an account. Much more newbie friendly (more newbie friendly than all the Slack invite requirements). I believe the Portuguese channel https://riot.im/app/#/room/#drupalportugal:matrix.org (also world readable) ; and the Dutch language channel https://riot.im/app/#/room/#drupal-nl:matrix.org are both example that are native and you can just click to join. [There is also a general test channel world readable and non-registered public https://riot.im/app/#/room/#test:matrix.org if you want to look.]

markhalliwell’s picture

I've been following this for a while, but haven't yet commented.

Sadly, there are already several different ways this can happen and, quite frankly, it's starting to get really.... really annoying.

Do I use IRC, Slack, twitter, d.o contact form/email, issue comment... now something new discussed here???

Do we move to another 3rd party solution that may not have all the features we need/want?

---

I do think moving to a 3rd party solution is a bad idea, even if it's open source; primarily for the fact of reliance (and for the other various reasons stated above).

Not to mention that it will never fully encompass our community's needs, wants or unique use cases.

This is very similar to the "Abandon issue queues and move to GitHub" discussion that we've had before.

---

Yes IRC is ancient. No one is disputing that fact.

It is, however, just a protocol.

I think people are forgetting that how users connect to it and what client the user decides to use is, entirely up to them.

That being said, I think moving to any platform that forces a user to use their "client" is a very bad idea.

---

Ever since I took over Dreditor, I had a radical idea that I never quite made public: providing per issue chat "rooms".

Originally, I had looked into somehow connecting to the IRC channels and even dynamically creating Drupal specific "rooms", that could be used.

However, that would really put a load on any server and could be considered "spam".

So I started looking into other solutions, mainly WebRTC (which I believe is IRC's successor).

It's already implemented in over half of all major browsers and it's success is quickly growing.

---

The reality is that we often work on issues where it would be nice to collaborate in realtime on specific issues.

What if we didn't actually have to "host" a chat server and instead utilize PTP (browser to browser)?

What if we could integrate it with and on the site all of use on a daily basis?

What if we could know when people are viewing the same issue just by seeing who's in the issue's chat "room"?

What if we didn't have to "onboard" new people into using new ways of communicating by downloading apps or signing up for 3rd party services?

What if it was just there, on drupal.org, when users logged in?

Wouldn't it be nice?

---

I know this is a different approach and still a relatively new concept, however I really think it's worth considering.

And I'd even be willing to help spearhead the initiative.

freelock’s picture

@markcarver

I do think moving to a 3rd party solution is a bad idea, even if it's open source; primarily for the fact of reliance (and for the other various reasons stated above).

This is a big reason I'm a proponent of Matrix -- we're not reliant on a 3rd party. I host my own Matrix server, and am using it to participate in #drupal, #drupal-commerce, #drupal-migrate, and others. I am using the Matrix.org bridge, but if that goes away another can be set up. Anybody else can join there via Matrix.org, or their own Matrix server. Drupal.org could run a Matrix server, too.

That being said, I think moving to any platform that forces a user to use their "client" is a very bad idea.

Completely agree! While I'm evangelizing for Matrix here, I'm communicating with people on IRC using it today -- and they're on their usual IRC clients. There are several different Matrix clients to choose from, but with bridges, Matrix connects the silos and lets people use whatever they want. Matrix does bridge to Slack and Gitter as well as IRC, and there are experimental bridges to Telegram, XMPP, Facebook Messenger, and others.

Please don't go bottle up conversations in Slack. Riot (a Matrix client) is not far behind Slack in terms of usability and features, but far more open and not reliant on a single host.

Originally, I had looked into somehow connecting to the IRC channels and even dynamically creating Drupal specific "rooms", that could be used.

However, that would really put a load on any server and could be considered "spam".

So I started looking into other solutions, mainly WebRTC (which I believe is IRC's successor).

Now this is interesting... I don't think WebRTC by itself is a solution -- as far as I'm aware it's a transport for media. Matrix uses it for voice, video, and screensharing already -- but primarily peer-to-peer only works between two peers. For multiple peers, you need a server to "mix" the channels together so that everybody can participate.

But embedding a chat room per issue would be a very interesting solution. And (yet another) benefit of Matrix is that is can preserve history, make the entire chat visible to participants, as well as provide guest access. A chat room per issue could certainly be done -- embeddable Matrix chat rooms are on the roadmap for the matrix-react-sdk, possibly even as a GSOC project. And I've already started a Matrix API module...

markhalliwell’s picture

I don't think WebRTC by itself is a solution -- as far as I'm aware it's a transport for media.

WebRTC has RTCDataChannel, which allows for textual communication (i.e. chat).

For multiple peers, you need a server to "mix" the channels together so that everybody can participate.

A server isn't really needed for "mixing channels", no. The only server that is needed is STUN/TURN to setup the initial P2P signaling. Once a user has established a P2P connection with someone, the messages are broadcast by the person sending them. The "mixing" would happen (relatively) seamlessly in JS on the client side.

As far as "chat history" goes, I was imagining that we'd have a button or something that just posts to the issue itself (could even be automated at some point). No need to setup a whole new database and continue the discussion fragmentation we already have around issues.

---

However, the more I read up on Matrix, the more it sounds like it's just a superset of WebRTC with some extra flavor (which I'm fine with... same principle really).

Considering that there are native client SDKs for nearly everything, including JavaScript, I'm definitely inclined to perhaps pursue this route more.

First and foremost, I was imagining creating a d.o specific implementation.

People shouldn't have to worry about downloading, installing, signing up or paying for another service.

After that, another exciting prospect that can be accomplished with the above JS SDK is the ability to create a dedicated/native desktop application using Electron (supports all three major OS: Windows, Mac and Linux) and is actually what Slack uses to build its desktop app.

This would, essentially, allow us to just reuse the code already deployed on d.o but just wrapped in a "native" app.

Using a module/drupal interface for this kind of UI will be really challenging. I think our best bet would be a Node.js/react app that can be browserified/rendered on the site, kind of like what I'm doing with #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features.

freelock’s picture

@markcarver Yes, it's a pretty great platform... we use a Matrix chat bot we've written to handle deployment of all our Drupal sites, among other things...

Node.js/react is definitely the approach I'm taking -- node.js for bots, and React for embedding a chat component on the page. I think the main challenge of implementing something like this in Drupal is getting anything from the chat back into Drupal -- given that long-running PHP processes is not typical of most hosting. But there is another alternative -- the "application service" API for Matrix is capable of sending notices to an external API. So we could set up an app-service and have it receive messages from Matrix to handle as it sees fit. That's not something I've done yet, but there are a growing number of bridges that use this API, and aside from needing a Matrix homeserver that gives permission to the application server (Drupal) -- I don't think it's particularly difficult to use.

So... I would think the main thing to do is design what the UX might look like, and that might suggest whether it's better to have a simple node.js bot to send updates to Drupal, or create a Drupal/Matrix app service that's more direct... or keep the actual "integration" much simpler, with nothing sent back to Drupal, just a standardized room creation mechanism using React... (if we don't need to get data back into Drupal.org, I don't even think we'd need a Node.js component, aside from bot-type behavior).

Cheers,
John

markhalliwell’s picture

I think the main challenge of implementing something like this in Drupal is getting anything from the chat back into Drupal...

Which is why this related issue is so important. If we could open up d.o's API, it would allow us to more easily integrate via a simple JS AJAX call to a specific/dedicated endpoint.

I would think the main thing to do is design what the UX might look like...

I think before any "design" happens, we need to identify our community's use case (i.e. needs and wants). We can design something absolutely awesome but miss the mark entirely.

that might suggest whether it's better to have a simple node.js bot to send updates to Drupal, or create a Drupal/Matrix app service that's more direct

I think any "bot" would be a secondary goal and entirely separate issue. The primary purpose of this issue is to evaluate an alternative to IRC (i.e. real time community communication). Thus, I believe any MVP would need to focus around that first.

if we don't need to get data back into Drupal.org, I don't even think we'd need a Node.js component

The biggest misconception about Node.js is that it's only meant for "tools" or "automation". It's just a programming language. One that allows for easier portability between server and client side implementations.

realityloop’s picture

Gitlab just acquired Gitter and plan to open source it by middle of the year, seem like it might be a good fit.

http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/

https://about.gitlab.com/2017/03/15/gitter-acquisition/

https://news.ycombinator.com/item?id=13877156

dqd’s picture

A maybe noteworthy hard debate about Matrix (much critics), just to bookmark it here for further reading. Mainly about Matrix's own view against XMPP in the beginning. Note: my intension is not to take down Matrix in this discussion here with this, nor to push it. I just read and investigate, so also about Matrix's ups and downs, and have no fixed opinion yet about it (lack of time).

freelock’s picture

The Matrix devs came from the SIP world, and had a lot of XMPP dev experience before getting frustrated by the lack of any consistent set of XEPs that could be relied upon to be implemented. And... in my experience, it's a vast improvement.

We ran XMPP servers for years for internal chat. We had a Jenkins integration, and always wanted to do more -- but we never federated, and there was enough of a learning curve we never got much more integrated with it.

More importantly, a crappy UX killed XMPP for us. Matrix, being much more like Slack, makes it really easy to have a room per project, invite whoever should be associated with that project, and easily find everything. Having synchronized history across devices, comprehensive search within a room (for its entire history, unlike the 10K limit of Slack) and IRC support as well clinched it for us. Having a bot available the first weekend that would provide a login link to every Drupal site we manage on demand made it instantly adopted by our entire team.

For us, Matrix is like an IRC bouncer that makes IRC much more like Slack... except completely free and open. No open source project should tie its main communications to a closed, proprietary silo... especially one that seems to be hostile to open source...

dqd’s picture

Thanks for your infos and insides about this, freelock. Much appreciated here.

lpalgarvio’s picture

Currently I have a working experiment that bridges the following services:
- Slack
- Riot.im / Matrix.org
- Gitter
- Telegram
- IRC

I'm doing experiments with some drupal and docker channels and private servers that I won't mention here, reasoning privacy and security issues.

The workflow is currently this:
Slack <-> Riot.im/Matrix.org via Slack's ingoing and outgoing webhooks apps
Gitter.im <-> Riot.im/Matrix.org via Riot's Gitter integration
IRC chat.freenode.net <-> Riot.im/Matrix.org via Riot's IRC integration
IRC chat.freenode.net <-> Telegram via FruitieX/teleirc bot at a personal private server

I'm hoping to improve this process with additional software, and also provide support for RocketChat. Currently it's a very manual process and requires admin intervention, channel by channel.

Let me know how I can assist.
PS: we have implemented a IRC <-> Telegram bridge for #drupaldevdays that had mixed reactions (technical vs attendee chat) and has been turned off. A proper implementation has to consider the channel audience/target.

geerlingguy’s picture

It's interesting (since nothing has been officially changed) to note that the IRC channels seem to be shedding many, if not most, conversations outside of support-related things. I've noticed the trend for the past few months, but the more recent drama in the community (which also resulted in our long time bot, the Druplicon, being banned—see #2863181: Druplicon's purpose changed - block it as we consider purpose/use of irc bot in the future) seems to be accelerating the shift to the drupal.slack.com Slack usage.

Ideally, I'd like to use IRC or some other more open protocol. But I'm also a pragmatist, and it seems like a lot of the relevant conversation and community members are either both in IRC and Slack, or exclusively in Slack now :/

ekes’s picture

I'll note it's certainly not all. I'm in 3 Drupal irc channels that are active. Two of which don't yet have one of the close alternatives yet.

I've experimented with bridging some of the channels slack<->matrix<->irc. The cultures between slack and irc and can vary and jar - not necessarily but expectations about messages are different. The difference between matrix and slack however is minor.

So as matrix can offer an open source (and open click-url and see chat, through to full registration and invite) option even for the slack channels. I'd say we could start bridging some of those slack channels to matrix. Who's the admin of drupal.slack? (bridging channels requires adding api hooks). Some of these could even be bridged back into irc, but I take that step a little more carefully.

fuzzy76’s picture

A proprietary network run by a company *known* to throw out open source projects if they become too large? That's a terrible idea if I ever heard one. :-/ Not to mention their terrible UX involving signing separately into each Slack you want to participate in.

ricardoamaro’s picture

I've been watching this thread for a while and it seems to me that what people are requesting from IRC is that it should have more automation, a common UI and still be able to accomplish what it has been doing for us all these years.
It seems to me that what we need is:
- to apply a better integration using an opensource chat solution on top of IRC . Freenode already has one https://webchat.freenode.net/
- have our Infra folks bring in a modernized and opensource version of our bot https://drupal.org/project/bot
There are several choices out there already mentioned in this thread, but for sure we need to keep ourselves Independently using FreeSoftware and not using some closed solution leaving ourselves out of options in case we are "thrown out".

Using FreeSoftware solutions everyone can still contribute to improve a bot, a webui or an integration, leaving the job of administrating these to the D.A. and volunteers.

geerlingguy’s picture

So, thinking further on Slack... based on some things I learned from discussions there

  • Slack might cut off the account if we reach 15,000 users (apparently there are that many across all the #drupal-* IRC channels this stat may be incorrect)
  • Slack charges ($5.00 * .15 (85% discount)) = $0.75/user for non-profits—that would be ~$2,000/month at the current number of users(!)
  • Slack hides any messages beyond 10,000 messages for the entire account—with recent drama, that means most less-popular channels have zero visible chat history. Not fun.

This doesn't sound sustainable to me, for so many reasons.

NWOM’s picture

Discord doesn't have any of those three downsides (no user cut off, no charge, no message cut off). If we're potentially looking into closed source solutions (like slack), then maybe further investigation into Discord would be beneficial in the interim. There are plenty of groups that I idle in that have over 50,000 users, and also others that have IRC bot integration (from and to).

frob’s picture

Let's not forget that slack is not, and has no plans to, start supporting open source communities. In order to lower the barrier to entry we would have to use some equivalent to the heroku app for user registration.

Can the idea of switching to slack please be put to bed? It is only more convenient if you work at an organization that uses it for internal communication. If not, then it is one more thing to keep open.

kevinquillen’s picture

Slack can also change the rules at any time - and as mentioned before, they did to other communities. Plus, for better security, logging, and policy enforcement, you have to go above the normal price tier and look at higher options. It is costly.

Don't get me wrong, I like Slack, it works for our company, but I don't see it working at scale or by cost.

freelock’s picture

Everybody in the past few posts seems to be arguing for Matrix over Slack, at least by their arguments for open source, non-restrictive alternatives. Why are people continuing to use it?

Regardless, I agree with @eke above, let's get whoever is an admin on the current Slack groups to assist setting up Matrix bridges. Then people can continue to use Slack if they really insist -- but the rest of us can participate via Matrix.

ivaat’s picture

Hi!

I do think that IRC is 1# one good place for people to come and ask questions. It will never go out. All other platvorms are not independent. Did check slack out. More for team work and free one seems to process data as well. Don't know about that privacy at end.

Perhaps solution is simple:

For crossposting minimalation link #drupal-support to #drupal + make #drupal-social active (add topic). for #drupal-social can be slack linked as well. There several softwares out ther what enable slack to irc. for #drupal-social that could be solution in terms of getting more people involved

lpalgarvio’s picture

@ekes
About Drupal Slack
#2864161: Change Drupal Slack allowed/installed apps

That said, like many people here and in other technology circles, I'm feeling much more confident with Matrix.org and RocketChat, both open source, than with Slack.

Matrix.org
open source, multiple official and contributed clients and servers
self-hosted and available as free unlimited service
https://matrix.org/docs/projects/try-matrix-now.html

RocketChat
open source, official client and server
self-hosted and available as free service upon request
https://rocket.chat/download

shrop’s picture

Is it possible to consider sticking with IRC and hosting a web IRC solution like https://webchat.freenode.net? The web IRC solution could be setup to make it easy to drop into #drupal-support. I experimented with Slack for a Drupal distro over the past year and we moved back to IRC. We found that many novice users had issues with Slack if they didn't use Slack elsewhere. Our team decided we would be ready to assist novices get going with IRC.

Thanks for your patience if that has already been recommended. This is quite a long thread.

heddn’s picture

Why can't we decide that we stick with IRC and let any and everyone bridge it to any and every technology on the planet? If you want to setup a bridge Slack. Good, go for it. If you prefer carrier pigeon, have fun. Has anyone else said anything about actually *replacing* IRC with something else, or just supplementing IRC with bridges for the past 159 comments?

RE: #159 there are already solutions that do that. See consensus around #50-#68.

Right now, this issue is essentially a venting board or bragging place for 1) why they hate IRC or 2) what technologies they were able to bridge into IRC.

Let's just accept it. IRC is here to stay. Long live IRC.

shrop’s picture

@heddn: Good deal! Thanks for the details. I am for keeping IRC and addressing specific improvements. May be time to break out specific improvements into separate issues.

frob’s picture

I am also for keeping IRC. If we want to spend some of our precious infrastructure time (not sarcastic, infrastructure time is precious) we should do it on either an upgraded alternative to the web IRC client, https://webchat.freenode.net with another cheaper option would be to just promote the freenode webchat client more.

ricardoamaro’s picture

Since i'm the Drupal group contact with freenode I would love to see some comments on the 2 proposals above at #151 in order to move ahead with some real outcomes from this thread, since people are a bit dispersed right now.

shrop’s picture

@ricardoamaro, I am supportive of both ideas on #151. Think starting two issues for these is the next step?

Antti J. Salminen’s picture

I think building upon IRC would be a good idea but I have some concerns about the split just staying in place when lots of people seem to already have migrated off freenode to the Drupal Slack.

ricardoamaro’s picture

@shrop yes, i think creating action items based on this discussion would be a good starting point. Today i went to slack and there is a huge crowd over there. Would be great to have everyone's constructive ideas and contributions based on IRC, since that's the general take of this thread.
Reading again the above i think #77 is a good solution for the first point.
And they have apps available for mobile
iOS: https://itunes.apple.com/app/irccloud/id672699103
Android: https://play.google.com/store/apps/details?id=com.irccloud.android

#drupal
#drupal-contribute
#drupal-support

fuzzy76’s picture

I think a lot of the comments the last couple of days come from people that haven't read this entire thread yet, as most of these aspects have been discussed already. One major pain point with IRC is that you can't read previous history unless you are a) connected 24/7 or b) run a bouncer (proxy) on your own server. This is not ideal, and is a problem solved on every other possibility out there (Slack, Matrix, XMPP, Discord, Mattermost, Gitter, etc.).

ricardoamaro’s picture

Issue summary: View changes
ricardoamaro’s picture

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

geerlingguy’s picture

@fuzzy76 - note that unless we pay vast sums of money, Slack only allows access to the past 10k messages. With the flurry of activity this week, that means most of the channels on Slack have zero history anymore because other more popular channels have pushed past the 10k limit and do so on a daily basis.

Antti J. Salminen’s picture

@fuzzy76: That one's not that difficult to solve with an IRC bot though. Admittedly the interface isn't quite as nice but it definitely works. In fact the Drupal IRC channels could have had that with Druplicon but a deliberate decision had been made to turn the logs off for most channels.

kevinquillen’s picture

@geerlingguy plus, I think if it were the new 'official' chat channel for drupal.org, people would want SSO so there is solidarity between their Slack account and drupal.org account. You don't get that unless you pay $12.50 per user per month instead of $6.67.

fuzzy76’s picture

@geerlingguy As I stated earlier, there are a lot of things wrong with Slack. My comment was not an endorsement for that particular service.

@antti that is not solving the problem, that is duct-taping a hack. Sort of like mirroring two mediums (or channels) through a bot also is. (Or using a cvs-era patch-based workflow on top of git, but let's not digress too far).

frob’s picture

@fuzzy76, no it is not a hack or duct-tape solution. IRC is a chat protocol that we can build our own clients around. Every chat system is based on very similar protocols.

While I would be lying if I said that I read every word of every comment. I did skim through it all and I read anything that was replied or mentioned. The general consensus is that there is no consensus. The is no perfect solution and thus in order to get this issue marked as fixed. It seems like the best solution is what was most recently suggested.

- updated or better promoted IRC web client
- opt in logging
- modernization of chatbot #2864658

frob’s picture

Issue summary: View changes

I did some organizing of the is, alphabetized (somewhat) the irc foss users. Assed wordpress to the irc users because they have not stopped using irc for support and are only using slack for wordpress contribution.

Antti J. Salminen’s picture

@fuzzy76: I wouldn't go as far as calling it duct-taping a hack but I admit it's far from the ideal UI for such a thing. Some kind of a multi-user bouncer setup for everyone would be the better solution to build just on top of IRC but also much more difficult to implement.

@frob: How would opt-in logging work? everyone can set if their comments appear in the public logs and for those that don't want to the logs will just have lines that indicate someone said something? If so, interesting idea... has it been used somewhere previously?

https://www.drupal.org/slack currently lists 8 different Slack teams. I'd love it if things could be at least slightly less fragmented and for that I think there would need to be something more appealing than just an improved bot and promotion of the webchat. Whether the best choice would be one of the fully free/open source solutions or something like IRCCloud I don't know. IRCCloud does have the advantage of probably being the easiest to get up and running and even if it's not an entirely open-source self-hostable solution, it's just an addon.

Antti J. Salminen’s picture

Issue summary: View changes

Convos is Another potentially interesting option that works in a way similar to IRCCloud in that it's just added on top of IRC but is F/OSS and has to be self-hosted. Looks like it's in active development. Added it to the list.

frob’s picture

@antti I haven't thought too far into opt-in chat logs, but what you said is the basic idea. I just thought of it while I was typing, and I should have brought it up in a comment first. Now that the DA is managing the bot this kind of thing is technically possible.

I expect there is more than 8 drupal channels on slack. It seems like we are hemorrhaging users from IRC to slack. This is a very bad thing and one of the reasons I want to get this issue resolved. Slack is not designed for harboring open source communities. This is why they have such a steep pay-scale. Everything about slack is designed around corporate team communication. I am not saying that we need to stay on IRC because IRC is the way we have always done it. But all the benefits (listed below) of IRC vs the two benefits of Slack for open source really makes the decision (to me) an obvious one.

Arguments in favour of IRC

  • IRC is an open standard
  • Users can choose their own client
  • Many other FOSS projects use IRC, so contributors to those projects can easily join the Drupal channels
  • Optional user creation, no register user required for use

Other open source projects still using IRC besides Drupal

  • Ansible
  • Asterisk
  • bash
  • drush
  • docker
  • debian
  • Fedora Project
  • git
  • grav
  • GNOME Desktop
  • linux
  • python
  • puppet
  • Mozilla
  • mysql
  • nginx
  • OpenStack
  • postgresql
  • php
  • Ruby On Rails
  • sensu
  • ubuntu
  • vim
  • wordpress

Arguments in favour of Slack

  • Users are already migrating
  • I use it at work so I already have it open

Even wordpress which uses Slack for core development, doesn't endorse the use of slack for general support.

I am attacking the idea of using slack because it is where people are going, not because it is the proposed solution. Many of the other open source solutions also have merit.

I have not seen Convos before, looks interesting. I expect running anything like Convos would have to also get approval from freenode.

I apologize for the rant.

realityloop’s picture

I think the biggest risk, which we are already seeing is fragmentation.

I vote for something open source (looks like Matrix is the frontrunner here to me).

Anyone using multiples of different messaging systems should also check out: http://meetfranz.com/
And the plugin repository: https://github.com/meetfranz/plugins

Seems like it wouldn't be too difficult to make a plugin for one of the web based Matrix clients.

frob’s picture

Issue summary: View changes

@realityloop, I dunno. From everything that I read about Matrix in this thread, Matrix doesn't sound like an IRC replacement. From what I have seen in this thread there is no IRC replacement. All talk has been of using Matrix as an IRC bridge, which plenty of people seem to be doing. Using IRCCloud isn't replacing IRC either.

I'm going to put my neck out there and mark this as RTBC Needs work (I have updated the IS with things to do). We stick with IRC. Though a plan needs to be made to stop the migration of users out of the official support channels, or better define official support channels, I think this discussion is resolved.

frob’s picture

Status: Active » Needs work
markhalliwell’s picture

From what I have seen in this thread there is no IRC replacement. All talk has been of using Matrix as an IRC bridge, which plenty of people seem to be doing.

No, that's just one way to use Matrix. Matrix is an open protocol, just like IRC, but built with newer technology, concepts and features.

It semi-mirrors what WebRTC is attempting to accomplish.

There are many different ways to use Matrix:
http://matrix.org/docs/projects/try-matrix-now.html

We stick with IRC.

Obviously IRC cannot support the features we need.

That is why this issue exists and why people are trying find other mediums that do.

I think this discussion is resolved.

No it's not.

marcvangend’s picture

Status: Needs work » Active

Matrix doesn't sound like an IRC replacement. From what I have seen in this thread there is no IRC replacement.

That sounds like saying "email cannot replace snail mail". Of course it's different, but given how many people are switching to slack already, I can only conclude that tools like Slack/Matrix are seen as replacement, and probably even an improvement.

This issue will only become "needs work" once we agree on a plan and start implementing it.

Antti J. Salminen’s picture

Seems like what there's agreement about is that we can't stick with just IRC and that while features that Slack offers are desirable, it isn't really an option.

Also seems like there's support for having IRC still be around as more than just a gateway you can connect through (so not Slack-style). That makes sense to me also because it would mean not asking the existing userbase to move to yet another platform. Many would also prefer a solution based on free/open source software.

Matrix and Convos look to be options that would tick all these boxes. IRCCloud gets close, but if there is a fully free/open source software solution that would be preferable.

Matrix being even able to bridge Slack in addition to IRC would certainly help adoption and it could be offered as the official solution. If it has the major pain points covered and works reliably I support choosing it too.

larsdesigns’s picture

I second the statements and opinions of @greggles.

I can add that IRC is the most inclusive chat system for our community and when provided by freenode it supports the nature, culture and values of Drupal as an open source software community.

An area we can work on is to create easier access to IRC. Perhaps providing recommendations for IRC client software, and improving the instructions for getting started.

frob’s picture

Issue summary: View changes

This issue is confused and will go nowhere if we do not focus. Lets get a list of requirements since this has primarily been a scatter shot of suggestions thus far. These are the requirements thus far:

Requirements for chat system

  • bot integration,
  • Being able to get messages even if not connected to it,
  • Probably not self-hosted
  • @todo add more requirements

Seems like what there's agreement about is that we can't stick with just IRC

This isn't an agreement, this is an argument. There is just as much of an agreement that IRC is the best solution at this time. There is nothing wrong with IRC as a protocol and it can do all the things that we have listed as requirements. In fact, it does them all right now.

We have a list of "problems with IRC", but we need to update the Issue Summary to convert this into a useful issue where we can actually gather options and evaluate them without becoming a pro/anti-IRC/SLACK/CHATSERVICE issue. If it isn't done by the time I circle back here then I will attempt to rewrite/focus the IS by the end of the week. In the mean time I will add two requirements.

  • Open source
  • Not an island for Drupal

Open source

Drupal is an open source project and it should be important that we embrace open standards and open source. It can be argued, and I would agree, that this might be more of a nice to have than a requirement, except that with the mass of open source chat systems out there I believe we can find one that is best-in-class.

Not an island for Drupal

I am thankful that we have not seen a "lets just roll our own" solution for this mentioned, but I still think we need to be clear about this. If we move somewhere it shouldn't be a place that only Drupal exists. A self-hosted web client isn't a bad idea, but those of us who are involved in more than a single open source project shouldn't be required to keep an app running just for "Drupal Chat."

Antti J. Salminen’s picture

@larsdesigns I mostly agree but there are two things that lead me to believe that better documentation would not be enough. First, I think it is a good observation that there is an issue with the usability of IRC compared to Slack caused by the lack of a nice web-based interface and the barrier of entry having to install a (better) native client creates. Freenode webchat exists but it feels very dated and not something even I would like to keep using as the way to get to IRC while Slack's web interface is good enough for someone to do that. Secondly, at this point we also have to consider that a good number of people that have previously been perfectly capable of using IRC have already made the choice of moving their discussions to Slack so they seem to prefer something that it offers.

@frob:
You're right, I misspoke about there being agreement about just IRC being enough. What I was getting at and I'm hoping nobody would object to is adding optional functionality on top of IRC with Matrix or one of the other mentioned solutions that are able to do that.

markhalliwell’s picture

Issue summary: View changes

This isn't an agreement, this is an argument. There is just as much of an agreement that IRC is the best solution at this time.

No. That's your opinion. It doesn't change the fact that IRC is severely outdated and lacks much needed features.

There is nothing wrong with IRC as a protocol and it can do all the things that we have listed as requirements. In fact, it does them all right now.

Um... no it doesn't. Which is why we have severely fragmented our community's communication in regards to which mediums/platforms are used.

In the mean time I will add two requirements. Open source Not an island for Drupal

I agree with with the open source, not so much the "Not an island" part. Yes, we'd have to create a "homeserver" for Matrix (see IS), but that's rather trivial.

---

@frob, I don't think you understand that Matrix allows us to "keep" aspects of IRC and would even allow us to bridge with IRC. Just because you are fine with IRC, doesn't mean the rest of us are. Please stop saying "that it's fine as is". It's clearly not.

---

I've updated the issue summary to be a little more concise with what has been discussed above.

markhalliwell’s picture

Issue summary: View changes

Minor formatting

frob’s picture

Issue summary: View changes

@Antti: sorry, I misunderstood what you wrote as to mean that we need to replace IRC with some other solution. I am all in favor of attaching more tech to our freenode hosted IRC.

No. That's your opinion. It doesn't change the fact that IRC is severely outdated and lacks much needed features.

IRC is old and that is a bonus, not a failure. It has been around for along time and it has continued to evolve to suite its use-case. We are talking about chat protocols and it is important to not throw the baby out with the bathwater just because chat protocols have seen a resurgence in recent years. The abundunce of options doesn't make our current choice any more or less useful.

We need to focus on features and not get bogged down on implementation. That has been a real confusing part of this issue. Everyone is looking to solve the problem and everyone is moving in a different directions. We need to know what direction to move before we begin working on an implementation. We have a list of IRC complaints, that part is done. Now we need an absolute list of required features. The list has been started in the IS.

@markcarver, thank you for focusing the IS.

I added gitter as a proposed option, and moved webrtc and "user is typing" indicator out of requirements and I doubt either is deal breaking.

frob’s picture

During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC.

Does anyone know where this paragraph came from. It doesn't really make a whole lot of sense but it sounds like a quote. We need this paragraph cut or fixed. I don't know what it is supposed to say.

heddn’s picture

I think that was a quote from the Drupalcon core conversation that launched this issue.

markhalliwell’s picture

Issue summary: View changes

@frob, typing indicator and RTC (audio/video) aren't "nice to haves". They are a requirement. These are features that don't exist and force people go to other mediums that do have them. These are probably the biggest reasons for our current community communication fragmentation.

I think you're confusing what some people won't use or don't care about vs. what some people need (and why this issue exists).

Please stop trying to belittle this issue.

I also took out the verbiage about the Druplicon. Current implementations doesn't change the fact that bots aren't really a native part of IRC and require a manual and separate persistent instance/connection to be maintained.

pwaterz’s picture

I think it's time to just pick one and go with it, and adjust our approach when it's needed. So much time is being wasted on arguing one chat client for another. I think HipChat and Slack have been vetted by the tech community as being good choices in this space. The company I work for went through this same process about two years ago, and we chose HipChat because it was more robust than Slack at the time. I think they both offer similar features, and someone with authority in the Drupal community needs to just pull the trigger. The longer it takes to make the decision the more productivity is lost in entire Drupal eco system. Does anyone think it would be a good idea to create a survey monkey survey to allow us all to cast our vote?

markhalliwell’s picture

Issue summary: View changes

I think HipChat and Slack have been vetted by the tech community as being good choices in this space

Yes, for small to medium sized business/teams. Not for a full blown community like Drupal.

I've updated more of the cons in the Slack category.

lpalgarvio’s picture

  • IRC usage is dropping on IT circles for maybe a decade now
  • IRC sucks on mobile
  • IRC doesn't keep track of channel logs or your private conversation logs. You need applications for that, external synchronizations, per user, costs money, many aren't FOSS
  • IRC doesn't do voice calls.
  • IRC doesn't do video calls or conferences.
  • IRC is a pain to share files.
  • IRC does not show media, such as pictures and maps.
  • IRC can't share stuff permanently.
  • IRC doesn't support login by email address or phone or external credentials.
  • IRC services is probably lacking in integrations (web hooks, notifications, etc).

IRC........
Can we quit arguing that IRC is outdated or not? It is. It's a fact.

However it does well a lot of things. And a lot of people like it and use it. And it's another drama if it ends.
Can we revise the topic description and title to something more friendly, like

Evaluate other communicate mediums to be officially supported and synchronized with IRC?

Major tasks:
# - Add additional supported protocols
# - Improve IRC with a better bot
# - Connect it and synchronize channels to other protocols

This way it suits everyone (I think).

It's also been overwhelmingly repeated and discussed that Slack isn't what we need, for many reasons.
Some solutions are standing out for ease of use and no costs, other than the ones associated with bots:

  • Matrix.org
  • Telegram (has recently added voice calls)
lpalgarvio’s picture

Issue summary: View changes
lpalgarvio’s picture

Issue summary: View changes
lpalgarvio’s picture

Issue summary: View changes
lpalgarvio’s picture

Issue summary: View changes
frob’s picture

Issue summary: View changes
Related issues: +#2864658: Modernize the IRC Drupalbot
lpalgarvio’s picture

Issue summary: View changes

recover lost edition

lpalgarvio’s picture

Issue summary: View changes
ivaat’s picture

@lpalgarvio

don't know how irc sucks on mobile phone. depends what client is used. people who chat via irc have questions and it's more chat not tweets with short messages...

-----

this topic seems to be old and actually not a issue.

for #drupal, #drupal-support IRC using
for #drupal-social made suggestion to link for experiment slack with irc (software avaliable).

+ webchat and freenode has that already.

All other solutions seems to have purpose for this topic.

Perhaps summarise this by op?

lpalgarvio’s picture

@ivaat

What I mean by sucking on mobile is the experience you get with each connection that is interrupted.
It's highly disruptive, distracting and annoying to get spammed with jargon when using regular IRC clients.

Which can happen multiple times a day, considering things like, switching between WiFi and 4G, going in the metro, passing through a tunnel, going downstairs on a steel reinforced concrete part of the building, weather issues, and so on.

freelock’s picture

Nice changes to the issue summary!

I would think that #3 should satisfy just about everybody (other than those who can't get over their Slack addiction...). There's no need for anybody to stop using IRC. We can just bridge all the IRC rooms into Matrix -- and this is already available/done as "portal rooms" -- anybody on Matrix can simply "/join #freenode_#drupal:matrix.org" to get into the main #drupal channel, and use the same pattern to join any other IRC room on Freenode. So there's not even any action necessary to have #3.

However, there are a couple improvements to suggest: with support from an Op in each channel, we can set up an official "plumbed" room, which would allow us to make the history available to anyone (if desired), and not just users since they joined the room.

And the other improvement? Add links/instructions to the appropriate community pages, send new people to the Matrix rooms (as well as IRC) and remove the Slack link. Encourage people to use Matrix or IRC, and not Slack.

Some other thoughts for longer term improvements:

If the DA would like more control over the channel names, I would recommend setting up a Synapse server on a drupal.org domain, which would allow for better aliases. If you use matrix.org to create the bridged plumbed rooms, you end up with room aliases like "#drupal-contribute:matrix.org" or with portal rooms, "#freenode_#drupal-contribute:matrix.org". Better would be "#contribute:drupal.org"

With a drupal.org "homeserver", we might also be able to auto-login Drupal users using their Drupal.org credentials. There's already an LDAP authentication system for Synapse -- I'm wondering how hard it might be to use Bakery or Saml to auto-provision/auto-login Matrix accounts based on DO accounts. Created #2867466: Provide Matrix provisioning/authentication system to track this feature request, at least on the Drupal side.

Cheers,
John

hestenet’s picture

Chiming in from the Drupal Association point of view:

I just wanted to say that we're following this conversation closely, and we do want to support the community in finding a good solution here.

We don't want to step in while consensus is still being built, but we do see several ideas coallescing:

  • We want a technology with modern UX/features
  • We want to address fragmentation, which can really only be done by standardizing on an official option, or by offering an option with bridging capabilities
    • Any bridging solution is likely to require more ongoing maintenance and support.
  • Whatever we reach consensus on, it is likely that it will need official support from the Association, whether that is:
    • to establish a relationship with a service like IRCcloud to provide licenses for the community
    • to provide a Matrix/Synapse server to ensure the cleanest bridging experience
    • or something else

    And on the subject of 'something else' I do want to raise the point that there is an ongoing developer tools evaluation underway. And another update is likely to be posted to the community soon, laying out the short list of options:

    • We should bear in mind that GitLab is likely to be one of the toolsets on that shortlist, and it is already tightly integrated with Mattermost, and the soon-to-be-open-sourced Gitter.im - so there might be a natural opportunity there.

    All this is to say:

    • The DA would like to offer our support for a consensus solution. There is the caveat that we may not be able to prioritize that work for 6+ months, but that may not be such a bad thing:
      • It would allow us to see if natural options evolve out of the developer tools evaluation
      • It would give Matrix a chance to further mature, helping to address our concerns about maintaining that sort of alternative.
    lpalgarvio’s picture

    +++1 for the excellent plan detailed in #206 by @freelock.
    more than anything I had given some thought before

    Question remains, public matrix.org server (free) vs drupal.org server (has infrastructure costs but more control).

    @hestenet
    fantastic!

    @Matrix.org vs Rocket.Chat to GitLab...

    Matrix.org and GitLab integration:
    https://github.com/matrix-org/go-neb/issues/127
    https://gitlab.com/gitlab-org/gitlab-ce/issues/25634
    https://forum.gitlab.com/t/matrix-interoperability/5570

    Matrix.org and Hubot integration:
    https://github.com/davidar/hubot-matrix
    https://github.com/matrix-org/go-neb/issues/96

    Rocket.Chat and GitLab integration:
    https://rocket.chat/docs/administrator-guides/integrations/gitlab

    Rocket.Chat and Hubot integration:
    https://github.com/RocketChat/hubot-rocketchat

    Matrix.org to Rocket.Chat:
    https://github.com/matrix-org/matrix-appservice-rocketchat

    Hubot can talk via 3rd party plugins/scripting to:
    - GitLab
    - Gitter
    - IRC
    - Mattermost
    - Rocket.Chat
    - Slack
    - Telegram
    https://hubot.github.com/docs/adapters/

    There seems to exist more and more complete integrations for Matrix.org, however this needs to be tested.
    https://github.com/matrix-org

    Some stats from matrix.org free server:
    - 7 drupal channels
    - #debian channel bridged to #debian on irc.freenode.net with 500 users
    - docker/docker channel bridged to gitter with 480 users
    - linode channel bridged to irc with 280 users
    etc

    The free server currently provides working integration with:
    - GitHub
    - IRC
    - Gitter
    - RSS
    - Slack
    I've tried all these out in the portuguese drupal and the portuguese docker communities.

    Twitter integration is broken on the free service and although there are integrations for GitLab and Telegram, they haven't included them yet in it.

    ekes’s picture

    Question remains, public matrix.org server (free) vs drupal.org server (has infrastructure costs but more control).

    I can't see why the DA would set up a matrix server. They've not set up an IRC server.

    As Matrix automatically federates a room when someone from another server joins it, this is this not so important?
    https://riot.im/app/#/room/#drupal-nl:matrix.org is also https://webchat.weho.st/develop/#/room/#drupal-nl:chat.weho.st

    If desired in the future you could have a chat.drupal.org that hosts an instance, but the chats could still be federated onto whichever other server.

    In practical terms at the moment. Slack continues to grow. IRC continues to be used and be 'officially' supported. There is a real and existing disconnect between chat tools, and rooms. People are also starting to use Matrix.

    I, and others, are already in Freenode IRC channels from different matrix servers. There are instances of native matrix channels too: #drupal-nl channel is native and then bridged into irc (and a slack channel).¹ I assume the Portuguese one is similar, and there may be others. These can be on one matrix instance, but you can join from your preferred one.

    While some regional slack instances have been bridged to Matrix. The drupal.slack.com one hasn't yet. To bridge slack channels does require the operators to set two webhooks. The DA didn't - so far as I know - promote the drupal.slack.org; there was certainly no consensus for it. There's really no reason to wait on such things before making it accessible without invites and with open source tools.

    * So there is nothing stopping publicising matrix rooms, bridged to irc, now.
    * The only thing stopping people use open source software to chat to people in slack is they aren't bridged yet.

    <footer>
    ¹ The difference for those interested is: in the first instance (IRC joined via Matrix) you don't end up with Ops on the room, the server sets everything. The second you get Ops, control permissions, but you need to get permission from the Op of the IRC channel to bridge.
    Why might you want to do this? Well you could make the channel truly public for example. Like you can see the channel anonymously, just on a web page, without logging in! It's not the default, people need to know that people not in the room can see what's happening (a bit like the public bot logs, but even more integrated and obvious).
    </footer>

    fuzzy76’s picture

    I can't see why the DA would set up a matrix server. They've not set up an IRC server.

    Because Matrix does integrations, while IRC doesn't. You could connect user accounts to drupal.org directly, you could auto-generate rooms for projects, you could push commit-messages to said rooms, etc.

    frob’s picture

    I can't see why the DA would set up a matrix server. They've not set up an IRC server.

    There is also no need to setup an IRC server, freenode is the place for that. There is no benefit to setting up and self hosting an IRC server for an open source project.

    I am really glad to see the refinement in the IS. We now have a list of requirements and some suitable options for reaching those goals.

    @markcarver I am not trying to belittle this issue, I think that stopping further fragmentation of the drupal community is one of the most important things that needs to be done. That is one of the reasons I was trying to get people to stop complaining about IRC or Slack and stop bragging about their home-grown IRC bridge solutions and come up with some requirements. We have now done that.

    I still consider the "someone is typing" indicator a nice-to-have feature, because in a room with 100+ people it can just cause noise or stop someone from typing at all while they wait for their chance to be heard.

    I still consider RTC a nice to have because I have only once in near 10 years of doing Drupal needed to get on a call with someone and that was for a local dug meetup and not for community support. It would be nice to have it supported by whatever we use, but I can just as easily use any dozen video chat services for that.

    It will be interesting to see the outcome of https://www.drupal.org/drupalorg/blog/technical-advisory-committee-forme... and if it causes anything in our list to change. One thing to note about gitter:

    No integration with our projects. Channels are made independently from the project

    This is no longer true with gitter. The whole system seems to be built around rooms per project. I would also add, minimal required maintenance and minimal custom development required as requirements to switching as well. Of course, this begs the question what "minimal" means, but that is up to the DA that will be maintaining this new chat system.

    wturrell’s picture

    Issue summary: View changes

    First, please read the additions I've just made to the issue summary (includes a few non platform-specific points)

    My TL;DR would be: whatever we choose, please can we keep things as simple as possible, minimising noise, clutter and cognitive load?

    FWIW I can speak highly of the web and iPhone version of IRCCloud (note I'm on a free account, but sleeping my Mac Mini at night still seems to magically hold the session open and avoid the 2-hour timeout). It's reliable and gets out of the way – with it in a pinned tab, I can go ages without being distracted by it at all, yet I'll still see notifications straight away. For me the biggest feature isn't scrollback, but the ability to turn off "Show nick changes, joins and parts" – people waste huge amounts of time re-reading these every time they check a chat window (even the condensed equivalent on Slack).

    I appreciate IRC for it's plain text feel, especially the lack of Emoji - I think simple emoticons like :) and :( communicate a range of feelings (also useful: words). I honestly find icons, avatars, animations, etc. a huge distraction when reading through a transcript because they appear more important than the surrounding text. Similarly, my gripe with auto-embeds, such as those in Slack, is that they take up a large amount of real-estate disproportionate to their importance in the conversation (and the excerpt that's embedded isn't necessarily the bit you want to read). I'd want the ability to disable or compact them. Note a benefit of Drupalbot's node summaries is they are all on a single line.

    I'm not sure how important integrated audio/video chat should be - I'd suspect most of the time people prefer to take time to think about what they say and then type it.... When we do have meetings, is there any real problem with using Google Hangout etc? I wouldn't want people forced into using video chat, it's important all participants still have an audio option. Also: make it easy to mute microphone, see yours/others connection quality to help diagnose problems.

    Clearly a single chat system is preferable (I have sympathy for anyone who is currently has to straddle both IRC and Slack) - but I'm unconvinced what we choose it is will make any significant difference to the number of people who use/contribute to Drupal - people won't be put off just because we're using Chat Foo or Chat Bar.

    Most activity takes place elsewhere (as @webchick once said: "issue queue or it didn't happen"). It's important for people not to feel out of the loop because they weren't participating in text chat/RTC, and it shouldn't be seen as a requirement to contributing to the project.

    So I'd disagree with the premise that Drupal currently "lives" on IRC, where it really lives (and must) is drupal.org.

    lpalgarvio’s picture

    Issue summary: View changes

    @wturrell
    Slack and Riot (matrix.org) do support voice and video calls with webRTC.
    I've tested these in the past and these functionalities are documented.

    Speaking of voice and video chat, in Slack voice and video calls are for pay in channels.
    For chat between two people they are provided for free.

    I'm finding very difficult to accept the arguments you've made, so I've made new corrections to the issue summary.

    frob’s picture

    Issue summary: View changes

    Please lets not argue and post counter-points inline in the IS. I combed through it and removed some duplication and extra information.

    Currently I think our issue summary shows clearly what the problems are and what we would like in an IRC replacement. Lets see what happens from the news in comment #207 and maybe adjust our expectations accordingly.

    wturrell’s picture

    (written pre #214)

    I primarily want to make the case for prioritising simplicity over feature set, and consider how what we choose could impact people's productivity (also, the fewer built-in features we insist on, the quicker we can implement something that does most of what we need).

    I took care not to directly back any individual solution. It is, however, perfectly legitimate to include some positive views about IRC in the issue summary to provide balance - leaving a one-side section misleads those unfamiliar with the subject and annoys those who are. This list of "Concerns people have voiced about IRC" has evolved into a list of features (or lack of them) - I went back and listened to the 2015 discussion that sparked this issue; while technical stuff was mentioned, I interpreted it as being as much about the group of people who simply don't have enough time to be on any form of live chat or chose not to because they believe the stream of information is too overwhelming. Additionally, there were those who thought they might be missing out on important discussions, but still felt it wasn't worth the effort. Whatever we do we'll struggle to solve that.

    I had written some longer replies to @lpalgarvio's comments but ultimately I also have spent too many hours on this issue today and would rather do something more productive than arguing for or against IRC, so briefly:

    - I'd endorse quite a few of @frob's remarks, including most recently about "someone is typing" not necessarily being a positive thing, and that RTC isn't essential (I'm aware there's no formal Drupal policy on which platform, nor should there be imho, but the DA and the UX group use Hangouts for their regular meetings and the archival to YouTube provides transparency to the rest of the community without costing money).
    - I disagree about integrated file-sharing, that nobody has mentioned it at all in the comments suggests it's demonstrably not a priority. People being in different places fragments a community, people sharing a link from Google Docs doesn't. Also not everyone needs (or wants) the links they share to be permanent (and indeed not everyone wants chat logs to be permanent actually), but those files we need to preserve already have a canonical location on Drupal.org - e.g. screenshots, patches and other work attached to items in the issue queue, policy documents, etc. Also, as I wrote earlier, I would resist the temptation to "embed all the things". Adding inline photos might sound nice, but wait until people start posting "amusing" animated GIFs in response to everything (I seem to remember in HipChat there was no way to turn those off…)
    - I stand by what I said about IRC being simple compared to the Composer, Drush, Git and other CLI skills we expect people to learn (and the learning curve for Drupal itself) and I agree with @crell's comments in #112. All chat systems have a learning curve - as far as the initial setup process is concerned, I don't think there's that actually a huge amount to choose between any of them, given all can now be web-based. And as someone who's unfamiliar to matrix and bridging, that's just as daunting to me as IRC might be to someone else. As far as everyday use, well, I find Slack's UI very cluttered, even when I turn as much of it off/down as I can. Please let's try and consider there will be a subset of users who feel the same way (and that's why many may have stuck with IRC). Also, to start with, we need to try and get all our *existing* users in one place whilst annoying as few of them as possible, then we can figure out ways to encourage others to join.

    lpalgarvio’s picture

    Good comments above,

    I'm not aware of all the possible configurations and customizations on many of the chat platforms.

    Among them, being able or not to turn off "someone is typing" or uploads, possibly can if at all be turned off at server level only, and not per channel, as these options don't exist on Slack or Matrix, at least, with the free hosted services (perhaps different with self-hosted Matrix).

    Animated gifs and all the extras are controlled via integrations/apps in Matrix and Slack at server and channel level, meaning, a server admin can approve / enable a set of integrations/apps, which in turn can be individually enabled per channel basis, by channel admins. I'm unaware if they can be force enabled for all channels.

    Important to note, on Matrix, non-channel admins can't change a channel integrations, and channel admins don't need to be server admins.

    In my view, webRTC is exactly essential, as we need to provide communities with a proper & functional way to communicate with voice and do conferences for the kind of events that require this (including but not limited to meetups, live conferences, public board meetings, etc). The world is dominated by closed source free/non free half-baked solutions that are generally not 100% synchronized or compatible with everybody's devices.

    This is exactly what webRTC tries to fix, with the end goal that all these proprietary chat platforms (skype, hangouts, talk, duo, whatsapp, etc) that failed to adopt XMPP and evolve it in collaboration, which instead did fubar EEE tactics, switch over to this new set of standards. While I understand not everyone will want to use it, there is so much to gain from using it and allowing the communities to use it.
    https://en.wikipedia.org/wiki/WebRTC

    I can't give a precise indication about file sharing, regarding if files can and should persist forever, if they can be purged automatically after X time, or again, if they can be disabled. But having them creates new possibilities. Sending a file over a channel becomes more accessible than putting it over Google Drive or Dropbox and requiring a jump to another site and requiring (or not) a login in that same site.

    All the complicated stuff about Matrix and Slack rests alone on server admins and channel admins, or on special features like device approval, with not many people will use and is optional. Everything is very much simple until you decide to create channels (Matrix does offer a lot of options on this).

    In comparison with IRC, setting up channels properly (registered) is equally complex, but I find registering and configuring an account on a IRC server more complicated than on any of the other services described in this issue.

    I tried first Matrix (with Riot client) and didn't found it over complicated. I did find Slack and Gitter overly simple, with limited functionality (at least on the free versions).

    Cheers

    MustangGB’s picture

    We use Slack in our offices and it works fine for us, however in such a large community as Drupal is having less than a week worth of message history makes it completely useless.

    dqd’s picture

    Sorry that I didn't had and still don't have the time to read all comments here. It feels disrespectful but it isn't. This discussion is cluttered over several discussions actually and spread over a long time so that all the effort of people trying to explain their POV will be lost in the nirvana of this long scroll page. It's sad to see this but unavoidable.

    Tell me if I am wrong, but something what is missing from my flying visits all over the spots was, that somebody with more insights has mentioned to compare what other developer groups have in process of planning and if there are maybe similar discussions going on, which we should link or embrace to take a look over.

    Many of you will remember when the Drupal community got a hard and long discussion going on regarding its sometimes "isolated" position and solitary choices made apart from what's up around, and while I have to admit that I didn't understood every 100% concerns, I see the positive effect on Drupal 8 integrating with Symfony and Twig apart from code regarding community efforts. And while some old school Drupalianers maybe have mumbled against it at first place, many others have joined and communities have started to mix up and to automatically grow on both ends. It was refreshing. With some loss of course. But that's life. Something to watch all over many different situations in life and work. At least for me being long enough in a position to do so.

    As a project and company lead I have spoken last week to some of our employees, the developers in the company, and stated that I more and more see a real issue rising in the huge fragmentation going on in Open Source development (look at Linux Distros and DEs) over the years. And while I am an Open Source advocate, I still look for improvements to consider all the time. And to rise this issue is such one, and important. The unremitting split of man power is a huge issue in Open Source and "libre" community driven development because of developers hubris not willing to merge or to think outside the box. Or even worse: to believe to be the only small group of people to know what is best to do and split/fork/reinvent/seperate from the others.

    And that's why I would love to see more consensus here between large communities like Drupal with Symfony and Twig etc. regarding chat solutions. Like it was consensus with IRC back in the days. And that's what it made so available and improved (and maybe still is? Who knows). Please consider that improvement and availability has a strong relation to the consensus of many communities using it. As more consensus regarding this issue here with other developer communities will rise, the more future proof and less time consuming it will be to maintain.

    That's why one of the most important marks which have been made here, was, that some solutions integrate well with IRC. I saw my eyebrows perking up in that moment. Simple as it is: Integrating is the opposite of separating.

    betz’s picture

    Sorry if I missed it, but who manages the current slack account for the drupal rooms?
    We would just want to create bridges, so everyone can use their favourite app/service and be happy.
    :)

    betz’s picture

    Just want to link to another issue at #2885060: Drupal Chat Bridges IRC <-> Matrix <-> Slack
    Made an overview of most channels, on irc and slack side.
    We also started most matrix rooms on matrix.org (linked from above issue).

    freelock’s picture

    betz++

    lpalgarvio’s picture

    lpalgarvio’s picture

    dqd’s picture

    betz++

    webchick’s picture

    While I'm pro-Slack from a "reduce the barriers to entry for contributors" POV, here's an interesting counter-argument. :)

    Last week, someone purporting to be drupal.org user @marvil07 started an online petition on change.org. Originally, this petition's title and body text were about supporting Megan and Dries in light of recent community controversy. After amassing 40-odd signatures, the owner of the petition switched to the malicious twitter account that's been harassing community members, and the title/text was changed to the opposite: asking for Megan and Dries to step down. (See https://twitter.com/merlinofchaos/status/895767767646748676 for before/after screenshots.)

    The reason this petition had any legs in the first place was because someone registered an account pretending to be @marvil07, and impersonated him on Drupal Slack (see https://twitter.com/RAKESH_JAMES/status/895906793888530433 for a screenshot). Because Slack is a third-party service, we had no ability (that I know of) to determine that the email/IP address was a phony, and so several people (myself included) interpreted this effort as genuine when it was secretly an effort to get people to dox themselves by handing their first/last name and physical/email address to a bunch of anonymous people with malicious intent. :\

    Anywho. Don't think this changes anything wrt this discussion, just another day in #DrupalDrama land... :P

    lpalgarvio’s picture

    It was clever, and left me surprised, astonished and confused I guess.
    However bold and smart it is, it's also dumb and stupid, because it makes them look as trolls (the same thing they are accusing others).
    I think they are way past the assertiveness and correctiveness ( that they might had with any or all of their arguments) with these stunts, and I can no longer discern what is true, more or less true or false, or false.
    Can we just reboot or go back in time? Can't understand anything at the moment. Honestly, I'm starting to look indifferent to all this, and putting my trust that everyone together as a whole, can fix everything, instead of pointing more fingers.

    back to topic,
    There is no central login - no LDAP, no Oauth, no GPG keys, no device confirmation keys (Matrix uses this), no drupal.org account linking, no way to block accounts from being created with your nickname, no big brother ID card checking, no nothing.
    So no one can ever truly confirm one's identity, unless a method is implemented.
    But I guess this problem is not new. Anyone can post anything with a fake or temporary account in any protocol, even on IRC.
    Regardless, trust is always personal.

    greggles’s picture

    On irc we do have the ability to set up a cloak and we can only give out cloaks to people who have setup a password and password reset mechanism. Then there is some more faith the person is who they say they are.

    People who don't have a cloak have their IP show up to everyone in the world, for better and worse.

    That is not a super obvious element of irc and someone could definitely just use tor or a vpn and change their nick briefly and trick a lot of people.

    frob’s picture

    I do not think Slack is the way to go and I would argue that Slack only works to "reduce the barriers to entry for contributors" for people who use Slack. As someone who doesn't, it is just one more thing for me to run.

    On the topic of SSO, right now we are using Slack through a hack. If the DA where to actually choose Slack for this, then we could setup SSO through SAML. This means we can enforce d.o user account creation and federate the accounts to Slack. https://get.slack.help/hc/en-us/articles/203772216-SAML-single-sign-on

    kevinquillen’s picture

    On the topic of SSO, right now we are using Slack through a hack. If the DA where to actually choose Slack for this, then we could setup SSO through SAML.

    To get SSO though, that comes with a hefty annual fee for Slack, which requires the Plus tier ($12.50 billed per month per user annually, or $15 per user billed monthly). It gets costly very fast at that level for orgs. Unless, Slack were to have some plan for super large OSS communities, which I don't think they do - and ultimately still leaves them with the control to pull the plug or change the rules at any time.

    frob’s picture

    Right, Slack is prohibitively expensive. This is known. However, we could customize https://github.com/rauchg/slackin (which is what we are using for user signup) to verify user account creation against d.o for the initial account creation.

    markhalliwell’s picture

    Slack has been debated... to death... and it's not a viable option for our community.

    Please re-read the issue.

    lpalgarvio’s picture

    Well,

    a few more points

    In my opinion we still need to provide a resolution for it:
    a) delete all channels, block channel creation and have a single channel directing people to go to other protocols. but this will piss off people by forcing people to change.
    b) make bridges and let it be, simple, and still encourage people to go to other protocols.

    --

    Not plausible on my opinion:
    c) if you don't use Slack, the way it is, it's just standing there and making people confused.
    d) If you delete Slack, then someone will eventually create a new one, leading to the same problem.

    webchick’s picture

    Slack has been debated... to death... and it's not a viable option for our community.

    Please re-read the issue.

    People are "voting with their feet" and ending up on Slack, regardless of current policy or what the ~60 people on this issue say. drupal.slack.com has 4,406 members currently (707 show as inactive, which means "only" 3,699, compared to the 303 active in #drupal on Freenode right now). Several initiative teams have switched over to using Slack as their official meeting channels over IRC, etc.

    So it appears it is indeed a viable option, at least for a very large portion of our community, so we may want to stop debating and start accepting that fact, and instead focus on deciding what (if anything) we want to do about it.

    freelock’s picture

    Well, Slack seems like an extraordinarily bad choice as the home for an open source community -- a closed, siloed, proprietary software-as-a-service provider.

    That aside, most of us who are arguing here for Matrix are not trying to get people who love Slack to stop using it -- nothing of the kind. We're just asking for some assistance setting up a bridge to a completely open source alternative, which also happens to allow IRC users to participate. We're trying to bring the community back together again, without forcing anyone to have to choose a client they don't care to use.

    Why is this not an obvious thing to do?

    pwaterz’s picture

    I agree with webchick. I know it's proprietary, but it's a great communication tool. I think until something open source comes along that can offer similar functionality and stability the community should move forward on the decision. I think it'll be hard to find tool that offer stable voice and video chat that isn't closed source. If there are tools, then there's the added expense of maintaining infrastructure to support it. With Drupal having such a global reach, that could get very expensive. Also it's not something the community should be spending their time on, we should be focusing on core, contrib and making the platform stronger. I think Slack would enable us to do that more effectively. Also I would assume slack is pluggable so you can use different clients if you wish? Trying to get everyone to agree is impossible, a decision needs to be made and then re assessed in a few months if it was the right one.

    frob’s picture

    Slack is too expensive. It doesn't support us. They literally have no product for open source communities. They have promised one for years, but it is not a priority. We have found a way to make it work, but for now, it is a stop gap.

    People are "voting with their feet" and ending up on Slack, regardless of current policy or what the ~60 people on this issue say. drupal.slack.com has 4,406 members currently (707 show as inactive, which means "only" 3,699, compared to the 303 active in #drupal on Freenode right now).

    Those numbers only show one thing. People are not willing to put up with IRC as it is. When there is a low barrier to entry alternative they will use that instead. This is good information but it doesn't prove anything other than people prefer Slack to our current implementation.

    Several initiative teams have switched over to using Slack as their official meeting channels over IRC, etc.

    Good, they should. Slack is built for small focused teams and as a product it works well for this. Hopefully they are not reaching the message limit and what they are discussing doesn't get lost to time.

    A majority can be wrong. We have debated here the merits of different systems in this thread. We have only really come to one conclusion. Slack isn't the final answer, we need a solution. I don't think we have found it yet. Maybe this is because we are debating the wrong thing. We are debating a replacement for IRC. I think we have reached a post-IRC era and we need to rethink how this system of chat really benefits a project. What is the purpose of the rooms in IRC and how can that be better serviced with the tools that currently exist. There are hundreds of ways for people to talk to each other.

    What I am trying to say is: Maybe we no longer need an official ad-hoc chat room system. Just like how the forum was mainly off-loaded to drupal answers (for specific QA), maybe the type of system needs to be different and more purposeful.

    I am asking this as a questions:

    1. How are people using chat?
    2. Can we identify patterns that have solutions that can be implemented?

    Seriously, we have identified problems over and over again. Let look at some use cases, aside from idle random chat.

    @freelock, As far as setting up matrix bridges goes, open issues for specific issues. I don't see think this is the right place to ask for that. If Matix is implemented and its good people will start to use it.

    freelock’s picture

    There is a growing contingent using Matrix now, and an issue asking for Slack admins to add the necessary webhooks for the bridges - #2864161: Change Drupal Slack allowed/installed apps . We don't need to bridge all the rooms, but the large community rooms make total sense to do.

    Slack has quite a few downsides for large communities like ours:

    - Performance problems with large groups, undocumented maximum room sizes (what happens when we go beyond 5000? that's not far away, and at least 1 open source community hit a wall at that size).
    - Search becomes useless because Slack only allows free groups to view up to 10K messages, which can happen extremely quickly.
    - High cost to unlock features that Matrix and others have for free.

    @pwaters there are several open source voice/video chat systems -- we've found Jitsi to be pretty effective. Matrix provides WebRTC voice/video that works pretty well 1 - 1 today, and they are in the midst of replacing their matrix.org-hosted Freeswitch instance with a Jitsi back end anybody can host.

    We've also used BigBlueButton for webconferencing with good success.

    Matrix is also working on a really cool VR teleconferencing system -- think Holodeck... https://matrix.org/vrdemo

    But all of this is beside the point. The point is, there is no need to replace IRC entirely, people can continue to use it to participate in chats -- but if we can bridge IRC with Matrix and Slack, then everyone can participate on their platform of choice.

    lpalgarvio’s picture

    Reminding why Slack can't be used for this project or any team larger than X number of members as any kind of serious or main chat platform.
    - so-yeah-we-tried-slack-and-we-deeply-regretted-it
    - https://get.slack.help/hc/en-us/articles/201314026-Roles-and-permissions-in-Slack

    For me Slack is only and just a means of bringing people to Drupal through an additional chat platform, bridged, recommending but not forcing users to switch to another. Cause everyone will miss out on features that it doesn't has nor ever will have.

    lpalgarvio’s picture

    @freelock++
    @webchick++
    @frob++

    However, Slack doesn't have to be the one solution and there are already solutions that fit better:
    - Matrix
    - Rocket.Chat
    - Mattermost

    realityloop’s picture

    I hate to see the loss of history on a free slack tier, would be much better to use Discord which has searchable unlimited history, and voice/video and desktop screen sharing capabilities all free of charge..

    ricardoamaro’s picture

    @all
    We are making a bof at https://events.drupal.org/vienna2017/bofs/irc-and-bridging-drupal-community
    The bridging of IRC channels with Matrix is a much nicer and opensource way to solve this debate supported by dozens of people above.

    For those of you that still don't know how it works feel free to choose a client:
    https://riot.im/app/
    https://play.google.com/store/apps/details?id=im.vector.alpha
    https://itunes.apple.com/us/app/vector.im/id1083446067
    https://riot.im/desktop.html

    Morbus Iff’s picture

    Listen, I know all you guys like VHS and already have players and lots of tapes, but Betamax really IS better. You just need to buy a deck, replace all your tapes, and try it out, you know? You'll be a total convert when you do. Trust me!

    freelock’s picture

    @morbus iff Yeah, haven't you switched over to Wix? I hear it's the bomb! Can do everything Drupal does, no headaches! Let's all go ditch our open source and go proprietary...

    frob’s picture

    RE: Matrix, show us. Give me a url that I can go to, such as http://drupal.slack.com or http://webchat.freenode.net and start chatting.

    Until then, don't tell me that matix will be better, show me that matrix is better. I know, it's a bridge! But if I have to set up anything at all it is not an improvement over IRC.

    This is why slack works right now. Someone did that. They setup the Slack channel and they made it public and they setup the herokuapp to automate channel invites. That made it easy.

    ANSWER: I guess this was addressed in some of the first matrix comments. Freelock in #125 listed a bunch.

    See https://riot.im/app/?#/room/#freenode_#drupal:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-migrate:matrix.org, https://riot.im/app/?#/room/#freenode_#drupal-commerce:matrix.org for some examples (you do need to log into Matrix somewhere to be able to join Freenode-bridged rooms).

    Why were these links so hard to find. It looks like we already have Matrix bridges setup. So then, what are the next steps? Bridge into Slack? Can we use Riot.im for this for free?

    I am not asking about Matrix as the merits of matrix are all over the place in this thread. I am asking if anyone has looked into using riot.im as the web/app based IRC client? We need to read the EULA and Privacy Policy to make sure this is something that we can do. If so then just start editing doc pages to include links to the Riot.im freenode bridges.

    freelock’s picture

    It's much easier to onboard on Matrix/Riot than Slack, no invite needed.

    Those URLs work -- but we've plumbed better bridges now, so you can drop the #freenode_ part out of it and get to most of the Drupal rooms we've explicitly bridged. E.g.

    https://riot.im/app/?#/room/#drupal:matrix.org
    https://riot.im/app/?#/room/#drupal-media:matrix.org
    https://riot.im/app/?#/room/#drupal-commerce:matrix.org
    https://riot.im/app/?#/room/#drupal-console:matrix.org (actually bridged with gitter, there's no IRC)
    ... etc.

    You can go to https://riot.im/app/?#/room/#drupal:matrix.org right now, click "Join" and pick a username, and you're in... In the newly bridged rooms, you can even see history back to when the Matrix room was created. If you want to continue using that username, be sure to set a password and a recovery email, but those are optional...

    frob’s picture

    Issue summary: View changes
    Status: Active » Needs review

    I'm going to go out on a limb here and change the IS to reflect Matrix as the heir apparent. Or at least the figurehead we are leaning toward. Basically I am adding tasks to help us evaluate Riot as a service provider (the DA will need to chime in on that I am sure) and also list out some next steps for moving forward.

    markhalliwell’s picture

    The DA did: https://www.drupal.org/node/2490332#comment-12028868

    Which is why this issue stagnated for a while.

    ---

    GitLab + Gitter.im (+ Matrix bridge) sound more like the direction things are going.

    This is why I said what I said above: please re-read the issue.

    Yes, the issue is very long and, despite what the issue summary says, it seems people need to re-read the conversation to grasp how these conclusions were made and the reason behind why.

    tim.plunkett’s picture

    I was able to use riot/matrix to impersonate myself (an IRC nick with a password AND a cloak). That is bad.

    markhalliwell’s picture

    In basic "open rooms" that allow anyone to create any username they want, and isn't really tied to any sort of true authentication mechanism, sure... that's certainly possible.

    We can easily authenticate against real Drupal accounts if we needed, especially with something like GitLab + Gitter.im.

    markhalliwell’s picture

    Also, we wouldn't likely be promoting or using riot.im's software specifically, it'd be the bundled Gitter.im feature that now comes with GitLab, under the drupal.org domain likely.

    The riot.im links were just given to show that Matrix does have web UIs as well, with riot.im being the most prominent.

    frob’s picture

    I have been using riot alongside my IRC client. This is what that looks like.

    frob’s picture

    RE: @markcarver

    Yes, the issue is very long and, despite what the issue summary says, it seems people need to re-read the conversation to grasp how these conclusions were made and the reason behind why.

    Is there something wrong with the IS?

    Drupal console is a gitter matrix bridge, for those who want to test gitter integration. I don't see why running riot through its paces would stop the use of gitter in any way. It wouldn't even halt the use of Slack or IRC which is a big reason why it makes sense.

    Is there something wrong with the Remaining tasks? Why wouldn't we use riot.im's implementation? Our current chat is hosted on freenode so why wouldn't we continue to host general chat on a 3rd party?

    ricardoamaro’s picture

    Issue summary: View changes
    dqd’s picture

    @webchick Thanks for the inside @ #225. Didn't know about this WTF.

    From what I summed up for myself after being small part of this discussion all 2 months again is, that most of long term community members here, who really know about all the back and forth of it, embrace a scenario where some bridge is build to IRC to give an entry point for new community members which are used to more new chat applications without loosing IRC. But it should be sth. Open Source or at least supporting Open Source in a certain way with optional bridges for common other chat solutions. Is this correct? But isn't it already running via the drupal rocket web chat url brigded to IRC?

    But if this is the way to go, I worry a lil bit about the authentication security to prevent stories like the one described by webchick. Maybe I am wrong, since I don't know of all of their mechanisms, but shouldn't we limit the bridges to chat solutions only, which can be included in the authentication mechanisms D.O. uses or will use in future?

    PS: Did I missed it or was chat solutions embracing #mobile not part of the discussion yet?

    davidhernandez’s picture

    RE #225, just to add some extra info, that situation was resolved because Slack forces you to register with a valid email address. So when brought to the attention of an admin, the admin can see the registered email and verify it was an imposter. From a moderation perspective, that isn't possible with all the alternatives.

    Not to beat this particular dead horse, but I will repeat what I've said in other issues. As a community, we are inherently distributed. We always have been, and continue to be. Issue queues, forums, stack exchange, reddit, meetup.com, IRC, Slack (of which there are many), discord, twitter, facebook, etc. I have yet to see a strong argument to "decide" the community should be in one place, and what that place is.

    With the drama that has gone on this year, it has brought up many questions and concerns about communications, participation, and who controls it. I'm increasingly mindful of this, and concerned about trying to funnel and control it so deliberately.

    lpalgarvio’s picture

    It's becoming increasingly more evident that we will need a central authentication system (LDAP, OpenID, SAML, CAS, OAuth, etc) and local servers that can federate and authenticate against to dissipate all the security issues.

    Matrix and RocketChat allows this.

    Matrix with the synapse local server:
    - LDAP: https://github.com/matrix-org/matrix-synapse-ldap3
    - OpenID: https://github.com/matrix-org/synapse/blob/master/synapse/rest/client/v2...
    - SAML 2: https://github.com/matrix-org/synapse/blob/master/synapse/config/saml2.py
    - CAS: https://github.com/matrix-org/synapse/blob/master/synapse/config/cas.py
    - OAuth: could not find yet

    RocketChat with the local server:
    - LDAP: https://rocket.chat/docs/administrator-guides/authentication/ldap
    - OpenID: not supported yet
    - SAML: https://rocket.chat/docs/administrator-guides/authentication/saml
    - CAS: https://rocket.chat/docs/administrator-guides/authentication/cas
    - OAuth: https://rocket.chat/docs/administrator-guides/authentication/oauth/

    This requires however that we setup a local server (federated or not with the others).

    This is just a quick search, testing needs to be done in depth.

    ivaat’s picture

    I still don't understand whats wrong with IRC? Reminding of original topic:

    "At core conversation session by @kgoel at DrupalCon LA , 2015 on "Pain points of learning and contributing in the Drupal community" , several people mentioned that they don't like IRC and they don't get on IRC.

    During core mentoring at PHPWorld and people from other Open Source community said that they don't use IRC and its 1990's chat client which is way too old to use in the Drupal community and why Drupal still lives on IRC."

    I see mistakes at topic but first lets just go over of types of people community has. There are those who like to help via forum/question website (web interface). There are those who love using IRC.

    * IRC is not a CHAT client. IRC = Internet Relay Chat

    There are so many IRC client softwares out there that just pick what suits for you and connet to IRC server.

    IRC is very popular with teams or simply community. Make channel, register it and invite all you team members TO irc server.

    You can be anonymous in IRC if you like. Privacy is in your hands.

    With IRC is good that you don't have put up own IRC server but can be done very easily. There is also so many web based irc clients.

    Point is i havent seen any solid arguement why exactly IRC is not okey with modern days. Even if will be implemented #slack, matrix and what not people will use IRC and belive me. Lot of dissapointing supportes if IRC #channels gets taken away.

    realityloop’s picture

    @ivaat I think the main issue is persistance of history when your absent from IRC, not everyone knows how to set up a bouncer....

    webchick’s picture

    Since we've been going around in circles for quite some time, I'm going to attempt to bring this issue to conclusion. Wish me luck! ;)

    WHEREAS:

    - There is a "critical mass" of people already on Drupal Slack, who will not go back to IRC, for a variety of valid reasons.
    - There is also a non-trivial percentage of people who prefer IRC, for a variety of valid reasons.
    - Matrix (or similar technology) can apparently allow us to have our cake and eat it too by bridging these two so folks can use whatever technology they prefer, but we can still talk together as a single community.

    I PROPOSE:

    - We close this 250+ reply emotion-laden issue, and spin off a dedicated issue around setting up a Matrix server (or whatever) and begin working through the implementation issues (such as security/authentication/impersonation).

    Sound good?

    heddn’s picture

    Status: Needs review » Reviewed & tested by the community

    I'm good with the proposal in #259. Before we mark this as closed though, let's get those issues opened and/or linked in here. Then let's kiss this issue goodnight.

    heddn’s picture

    Hmm, maybe #2885060: Drupal Chat Bridges IRC <-> Matrix <-> Slack is that issue? If so, someone want to go ahead and mark this fixed?

    frob’s picture

    Status: Reviewed & tested by the community » Fixed
    frob’s picture

    Oh, and webchick++ heddn++

    Greg Boggs’s picture

    Frob has also spent significant time discussing and summarizing conversation about Matrix here:

    https://www.drupal.org/node/2864161

    ricardoamaro’s picture

    The closing proposal on #259 by @webchick seems to be a good direction. There is already a group of people that know how to move the creation of a matrix server forward. We can create an issue for it, ask the DA for a subdomain (maybe "matrix.drupal.org") to be used and meet in Matrix/IRC
    https://riot.im/app/#/room/#drupal-bridges:matrix.org & https://riot.im/app/#/room/#drupal-infrastructure:matrix.org

    Issue for this initiative is created
    https://www.drupal.org/node/2905534 "Setup a dedicated drupal.org dedicated matrix server".

    Thanks all for their patience and effort.

    lpalgarvio’s picture

    #257
    Saying IRC is private or privacy aware is missing out actuality. Compare it to Signal or Matrix. Limitations are at the protocol level.

    @webchick++

    webchick’s picture

    Status: Fixed » Active

    Dang, I knew that was way too easy. ;)

    Turns out, Matrix is not quite the panacea that I hoped it was. :\ In reviewing some of the comments in the implementation issue and talking more to @mlhess, @davidhernandez, @tim.plunkett, and others, there are a number of problems/concerns with a bridge solution like Matrix.

    Among them:

    • Allows re-use of usernames on Slack/IRC, making it trivial to impersonate others. (This is particularly worrying, given we already have evidence of people maliciously impersonating others.)
    • The only way to combat this on Matrix is to send Drupal.org data to a third-party, including usernames, e-mail addresses, and password hashes, which is a non-starter, from a security/privacy POV.
    • The folks prototyping this are asking for DNS records on *.drupal.org pointing to matrix.org. This is a non-starter from a security POV, because it opens us up to XSS, or other attacks.
    • There are people here who've expressed strong ideological preferences (on both sides) of their chosen platform. IRC, because it's free/open source and data doesn't get sent to evil corporations. Slack, because we can enforce things like registration with real e-mail addresses to help cut down on abuse, and the adoption of the Drupal Code of Conduct prior to joining. A bridge means you no longer get to choose your platform of participation; your content flows in both directions.
    • When there are bridged users present, this is not evident in the user listing until/unless they speak up in-channel. This is no good from a privacy POV, because you never know who's lurking, and would be a significant downgrade from either medium.
    • Private channels, such as #drupal-security, cannot be handled securely with any bridge mechanism.

    I think we're basically down to two options:

    1. Keep the status quo, with the community forked between two different chat platforms based on either technology preference or ignorance of other available options, and all the problems that entails. (For example, IRC-based initiatives being "orphaned" away from where committers and others they need to collaborate with to get their stuff done generally hang out.) If we do this, we should at least try and fix up the documentation in various places to make it more clear that both chat platforms exist.
    2. Change the official chat recommendation on Drupal.org to Slack; keep IRC around for those who want to use it, but no longer recommend it as an official place. Slack clearly has the critical mass of the community behind it, and those people aren't going to move (back) to IRC. And we have Mattersmost as an open source, self-hosted fallback if we get kicked off by the corporate overlords as some people fear. (Would need additional $$/infra support from the DA.)

    Assuming that the cons laid out here and elsewhere around Matrix/a bridge solution are indeed both valid and insurmountable, I think we should timebox the remaining discussion on this (to DrupalCon Vienna, maybe?), and then have someone (the Technical Working Group? the DA?) make the call, since whatever solution is chosen would/could ultimately become their expense and maintenance burden.

    pwaterz’s picture

    Thanks for the investigation webchick.

    Made a quick survey:
    https://www.surveymonkey.com/r/XKZPYBC

    See results at:
    https://www.surveymonkey.com/results/SM-6R9V6KKK8/

    webchick’s picture

    Hm. While I appreciate your mutual desire to bring this issue to conclusion, if we're going to do a survey, it needs to be much more broadly distributed than this issue, which is by definition only folks who've stumbled across it. (e.g. @Drupal twitter, Drupal Planet, announced explicitly on Slack, announced explicitly on IRC, etc.)

    However, I'm not really sure that surveys are the way to go here, since there are numerous technical, security, community, and ideological concerns here that won't be nuanced through a simple choice like that.

    pwaterz’s picture

    Wide spread distribution would be better, but why not see what the popular vote is with in this thread? Then bringing it to a wider audience if it makes sense. Having a complex survey will push people away, we are all strapped for time.

    There's never going to be a consensus on this topic, I think this thread proves that. I think choosing slack as the rich communication tool is the right way to go. Analyzing it to death isn't going to get us anywhere. If people want to continue to use irc that's fine, but the organizational choice should be slack. I think I saw in this thread that the board is already using it, so why can't we move forward?

    Apologies if I come off harsh, I just want this topic to move forward.

    webchick’s picture

    Fair enough; doesn't hurt to have it as a data point.

    Greg Boggs’s picture

    I wonder, has anyone gotten a price quote for Slack logging? If not, does anyone mind if I contact slack and ask?

    colan’s picture

    • The only way to combat this on Matrix is to send Drupal.org data to a third-party, including usernames, e-mail addresses, and password hashes, which is a non-starter, from a security/privacy POV.
    • The folks prototyping this are asking for DNS records on *.drupal.org pointing to matrix.org. This is a non-starter from a security POV, because it opens us up to XSS, or other attacks.

    [Option 2] Change the official chat recommendation on Drupal.org to Slack; keep IRC around for those who want to use it, but no longer recommend it as an official place. Slack clearly has the critical mass of the community behind it, and those people aren't going to move (back) to IRC. And we have Mattersmost as an open source, self-hosted fallback if we get kicked off by the corporate overlords as some people fear. (Would need additional $$/infra support from the DA.)

    The assumption with the above comments is that the only Matrix option is using matrix.org, and they're solved if we instead run our own Matrix server, which would be just as good as running our own Mattermost server. Can we add this as one of the options?

    davidhernandez’s picture

    If I remember correctly about every time this was investigated, the Slack cost would be something like $15k-$16k per year for the number of users we have.

    frob’s picture

    I really don't see how reading those comments came to this conclusion. If we run our own martix server and use d.o as the user authentication system (the same way it would have to be run with slack) then these issues become moot.

    I really don't see how a survey will help as well, but it is one more data point.

    The issue queue here starts with evaluation of riot and ends with:

    If Riot is not a long term option, create a strategy for implementing matrix in house.

    davidhernandez’s picture

    We should confirm that since I'm not sure how that figure was calculated.

    pwaterz’s picture

    Added matrix.

    lpalgarvio’s picture

    @colan++ has summed up what i was going to try to re-explain once again.

    Slack is not an option. Its useless as a tool for a large community.
    @webchick have you read or re-read the links i dropped about other communities on which slack failed horribly?

    Also, you are dismissing that we are implying Matrix/RocketChat/whatever to be @SSO bridged to Drupal.org via LDAP, CAS, SAML, Oauth or other method to REQUIRE a drupal.org account, and also a valid email address.

    About @privacy - you can't have full privacy if you want to patrol the community.
    It's one or the other.

    @pwaterz that poll is obscenely biased.
    Please remove it or refactor and then reset it.
    It needs options for ALL these to be fair:
    - Matrix
    - RocketChat
    - Mattermost
    - Gitter
    - Telegram
    - Hangouts

    Regards

    frob’s picture

    Many of these issues have been discussed at length this thread #2864161: Change Drupal Slack allowed/installed apps

    pwaterz’s picture

    Updated the survey with more meta data.

    At the very least this is proving useful for building a good survey.

    Greg Boggs’s picture

    I believe the Slack cost is calculated at a discounted rate of their pricing model based on currently active users on the server. But following up would be good because it's not a trivial amount of money.

    https://get.slack.help/hc/en-us/articles/204368833

    lpalgarvio’s picture

    thanks @pwaterz.

    webchick’s picture

    @lpalgarvio: I'm merely reporting reality. The reality is that regardless of other communities' experience, regardless of Slack's limitations as a platform, their pricing, etc. that's where 90% of the Drupal community is today, and they have no intention of moving to anything else.

    I don't think all of the concerns about bridging are resolved by hosting our own Matrix server, though some are. My understanding is the security team + DA is a flat-out "won't fix" to any bridging solution, self-hosted or otherwise, due to the additional risk of impersonation, privacy violations caused by lurkers, costs associated with developing workarounds around those issues, ongoing maintenance staff time/cost required, etc. Both IRC and Slack are currently free (as in beer), and entirely maintained by third parties so do not incur any additional burden on the DA/security team.

    freelock’s picture

    Wow, this seems like a bunch of mis-information floating around. @webchick #267, point-by-point:

    Among them:

    Allows re-use of usernames on Slack/IRC, making it trivial to impersonate others. (This is particularly worrying, given we already have evidence of people maliciously impersonating others.)
    The only way to combat this on Matrix is to send Drupal.org data to a third-party, including usernames, e-mail addresses, and password hashes, which is a non-starter, from a security/privacy POV.

    Not true. Matrix automatically disambiguates display names that are the same, by adding the globally unique "Matrix ID" of the user. It's trivial to see who is who when looking in the Riot client, and ban/kick as appropriate. The only real change here is that kicks/bans need to happen on whichever side of the bridge the abuse is coming from -- either the Slack side, or the Matrix/IRC side (the Matrix/IRC bridge does propagate kicks and bans).

    The folks prototyping this are asking for DNS records on *.drupal.org pointing to matrix.org. This is a non-starter from a security POV, because it opens us up to XSS, or other attacks.

    Again not true. The bridge works fine today, under moderation. DNS changes are only necessary if we want to support Matrix addresses in the :drupal.org namespace. Which would facilitate doing a central login/ additional options for reputation management, but is entirely optional.

    And if we did set up a :drupal.org Matrix server, it would not be pointing to matrix.org -- it would be pointing to whichever server we designate as the Drupal.org Matrix server. This isn't a Saas -- it's an open source server. Who manages SMTP for drupal.org? It's the equivalent of setting up a mail server (but in my experience, far easier to administer, having run my own Matrix server for nearly 2 years, and my own mail servers for over 15 years).

    There are people here who've expressed strong ideological preferences (on both sides) of their chosen platform. IRC, because it's free/open source and data doesn't get sent to evil corporations. Slack, because we can enforce things like registration with real e-mail addresses to help cut down on abuse, and the adoption of the Drupal Code of Conduct prior to joining. A bridge means you no longer get to choose your platform of participation; your content flows in both directions.

    This much is true -- but you also can't enforce a Drupal Code of Conduct on IRC rooms. Adding Matrix does not change the overall situation -- it does open up the Slack silos so that people opposed to Slack can participate in the same conversation, which to me is the entire problem here.

    When there are bridged users present, this is not evident in the user listing until/unless they speak up in-channel. This is no good from a privacy POV, because you never know who's lurking, and would be a significant downgrade from either medium.

    For rooms of > 1000 people, is this really a concern? Not asking to bridge every Slack channel, just the community ones where IRC has been largely abandoned. Druplicon used to have a public log of these anyway -- does Drupalbot?

    Private channels, such as #drupal-security, cannot be handled securely with any bridge mechanism.

    *splutter* You think IRC or Slack is secure?

    Agreed, bridges are not appropriate for rooms that have extremely sensitive content. Matrix E2E rooms are, and add a level of security you don't have on either Slack or IRC.

    I think we're basically down to two options:

    Keep the status quo, with the community forked between two different chat platforms based on either technology preference or ignorance of other available options, and all the problems that entails. (For example, IRC-based initiatives being "orphaned" away from where committers and others they need to collaborate with to get their stuff done generally hang out.) If we do this, we should at least try and fix up the documentation in various places to make it more clear that both chat platforms exist.

    This is the really lame situation we're trying to improve.

    Change the official chat recommendation on Drupal.org to Slack; keep IRC around for those who want to use it, but no longer recommend it as an official place. Slack clearly has the critical mass of the community behind it, and those people aren't going to move (back) to IRC. And we have Mattersmost as an open source, self-hosted fallback if we get kicked off by the corporate overlords as some people fear. (Would need additional $$/infra support from the DA.)

    This is another really lame situation we're trying to fix -- making an open source project entirely dependent on a commercial, proprietary SaaS with known hostility towards open source. Seems like a risk we can easily avoid here...

    Assuming that the cons laid out here and elsewhere around Matrix/a bridge solution are indeed both valid and insurmountable, I think we should timebox the remaining discussion on this (to DrupalCon Vienna, maybe?), and then have someone (the Technical Working Group? the DA?) make the call, since whatever solution is chosen would/could ultimately become their expense and maintenance burden.

    Really the only valid "con" I see here is the room membership list -- across 2 bridges, you're not going to see everybody who's in a particular room. But if it's meant to be a public forum, and public logs exist anyway, I fail to see why this is such a big issue.

    And the only other "con" is that there's one more channel that might need moderation -- and yet there are plenty of people available to moderate.

    Meanwhile, there are lots of other advantages to Matrix that make me wonder why people are interested in Slack at all, but that's a different topic. On this topic, the coming "Groups" functionality which should land in weeks, probably before Vienna, might provide an alternative to reputation management that makes Matrix a really compelling option.

    webchick’s picture

    I'm reporting back third-hand information. One of the other folks who are opposed to Matrix (I'm not one of them; I'm just pro-reality, and pro-wrapping this issue up before it hits 300 comments :P) will have to respond to explain their rationale.

    lpalgarvio’s picture

    This poll will need a proper clarification on it's page or elsewhere where it is shared.

    Otherwise it's probably going to be a battle of "do you want slack, the super popular easy chat that you probably already use vs matrix, the foss underdog which you probably never heard of (wth is foss anyways.. oh like drupal)".

    Just like Telegram faced vs WhatsApp.

    (But i appreciate the effort that @pwaterz has already done).

    pwaterz’s picture

    That's exactly where I am. I think we should give Slack a shot, unless there is something concrete stopping us. Then we can open a room called #replaceslack ;)

    lpalgarvio’s picture

    Issue summary: View changes
    ciss’s picture

    @pwaterz That survey won't produce useful data. Its results can easily be manipulated by voting repeatedly in a private window.

    frob’s picture

    I think we should give Slack a shot, unless there is something concrete stopping us.

    @pwaterz The many cons of slack have been discussed at length here. From the IS

    The why and why not Slack.com

    Pros

    • Some developers already have Slack app running
    • Has many of the above requirements
    • @todo

    Cons

    • Closed source/proprietary
    • In it for the money: https://slack.com/pricing
    • "Free" plan is intended for small to medium sized business/teams (Drupal is anything but)
    • Requires users to register
    • Architecturally has several types of limitations since their service is based on "small to medium" sized teams: https://medium.freecodecamp.com/so-yeah-we-tried-slack-and-we-deeply-reg...
    • Prohibitively expensive to get backsroll
    • Does not have all of the above requirements
    • Does not and will not support Open Source Communities
    • Allows users to easily impersonate other users on d.o [comment#233]
    • @todo
    webchick’s picture

    @frob: ...and yet, 3800 people are actively using it every day, which is an order of magnitude more than use IRC. Again, these are just cold, impersonal facts. All of the valid rationale in the world doesn't change them, unfortunately.

    Spoke to @hestenet at the DA. He said:

    "Any expense for the DA to run a custom server is not currently budgeted, and would likely need to be fund-raised for and/or approved by the ED/the board"

    Given that any such fundraising/approval process would take time/energy/focus away from the DA's other efforts, including improving our collaboration tools, I'm going to crystal ball a bit here and say that's probably going to eliminate the self-hosting option until/unless we have some kind of crisis like Slack decides to boot everyone off. (I personally would much rather have pull requests and real code review tools than a fancier chat solution, and think most people would agree.)

    EDIT: Also I totally just started the #replaceslack channel on Slack. 😂

    realityloop’s picture

    Perhaps we should at least set up http://slackarchive.io/ for the public slack channels?

    freelock’s picture

    Also I totally just started the #replaceslack channel on Slack. 😂

    I would join... if I could stomach Slack. How about we bridge that? 🏃

    frob’s picture

    Majorities of people make bad decisions all the time. And I don't expect this to happen over night. In-fact the only urgency that came of this was from this statement.

    Furthermore, while we appreciate that the existing unofficial bridge was set up for testing this notion, it is going to be shut down by IRC admins in 24 hours.

    Why? Where and When was this decided?

    If the DA started paying for use of Slack as an official chat service, I would save the DA around $168/month by no longer getting involved in chat online. My DA membership cannot possibly cover a Slack subscription. Not trying to sound threatening, just running the numbers.

    The status quo has served for a year or more, we can wait for more funding and for more planning to be made. This should just get in the queue, it is by no means an on fire priority until Slack boots everyone.

    lpalgarvio’s picture

    @realityloop So one proprietary solution (slackarchive) to fix one of the many problems of another (slack) to give people a way to chat and contribute to an open source software (drupal). Lets throw in some more proprietary solutions, paid or not, to fix it better, because it's too broken by default.

    Makes perfect sense.
    Without the emotion of Perfect Sense of Roger Waters.
    http://www.metrolyrics.com/perfect-sense-part-i-ii-lyrics-roger-waters.html

    webchick’s picture

    Status: Active » Postponed

    Ok, sounds like status quo it is. We can revisit once the DA's collaboration tool work is done, or an organization like Freenode offers a trusted Matrix server to lots of different open source communities who have this same problem, or Slack boots us all off, whichever comes first.

    In the meantime, spun off: #2905773: Document in places that mention IRC that Slack also exists and has lots of people actively using it

    ricardoamaro’s picture

    @webchick, @hestenet:

    Matrix and Freenode are already collaborating and have bridges setup since 2015

    : https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges...

    Up until the end of last week the bridge was limited to synchronising a fixed number of channels between Freenode and Matrix (#matrix, #matrix-dev, #openwebrtc, #vuc and #hypothes.is, to be precise), as well as any PMs. But as of Friday, with huge thanks to the admins over at Freenode, we can now bridge *any* channel in Freenode through to Matrix.

    If Freenode chose to work together with matrix giving them access to all channels, logically it's trusted by them.

    Since then lots and lots of features and bugs have been improved in order to make the Freenode/Matrix a clean and SECURE experience, including the availability of the dedicated server: https://matrix.org/blog/2017/05/12/update-on-matrix-org-homeserver-relia...

    On the other hand they have been aggregating more and more OpenSource Tools together with Matrix like JITSI https://matrix.org/blog/2017/08/23/introducing-matrix-widgets/

    So, yes, if we are still loving OpenSource and all that it provides then Freenode via Matrix is the way. It will be the best place for our community.

    davidhernandez’s picture

    Requires users to register

    Not everyone considers this a con.

    frob’s picture

    Not everyone considers this a con.

    @davidhernandez, before we get into these arguments again, please read all 297 previous comments. We have gone back and forth over every pro and con of slack, irc, matrix, and other services to a great extent.

    The issue summary is an accurate representation of what has been discussed from comment 1-297

    freelock’s picture

    FileSize
    43.43 KB

    @davidhernandez "Requires users to register" is a room setting in Matrix -- all Matrix users are registered, apart from "Guests" who basically have accounts with no password, which is entirely irretrievable if they lose their corresponding browser cookies.

    Room settings:
    Matrix room settings

    ... Our Freenode channels are not that strict in the first place. And if we set them to +r, Matrix can handle that -- I'm in several +r rooms on Freenode already, via Matrix -- including #docker and several other open source projects. (oh yeah, another benefit of Matrix -- "getting off the island")

    This is a policy question, and Matrix supports more different policy variations than either Slack or IRC. That's part of why we're trying to work out policy here -- and it's quite frustrating that the DA's answer is apparently one spawned entirely by fear of the unknown and shutting down contributions a bunch of us are trying to make, rather than actually trying to work out a solution we can all live with.

    webchick’s picture

    It's quite frustrating that the DA's answer is apparently one spawned entirely by fear of the unknown and shutting down contributions a bunch of us are trying to make, rather than actually trying to work out a solution we can all live with.

    This is an unfair classification. It's spawned by their desire to focus time/energy/money on a priority (improving developer tools) that has far greater benefit to the community. Which, given they have limited resources, is exactly what they should do, frankly.

    Nothing stops folks passionate about this from continuing contribute—e.g. experimenting on separate AWS/Slack instances to address the full extent of the "cons" list, working upstream to make the offering more seamless so it lessens the maintenance burden, etc.—in the meantime.

    freelock’s picture

    Nothing stops folks passionate about this from continuing contribute—e.g. experimenting on separate AWS/Slack instances, working upstream to make the offering more seamless so it lessens the maintenance burden, etc.—in the meantime.

    Shutting down the bridge stops us.

    I'm not going to contribute to a Slack solution at all. Nobody stood in the way there as people moved to it -- and when we come along trying to resolve the fragmentation we get shut down?

    pwaterz’s picture

    To me it seems like some new tickets should be spawned from this one exploring/defining integration steps for each option others feel passionate about. Thoughts?

    webchick’s picture

    I don't quite see how shutting down the bridge stops you from continuing to prototype to address the outstanding concerns. You just need an IRC server with some channels, a place to run Matrix, and a Slack instance, correct?

    The reason the bridge is being shut down, to my understanding, is because there are several blocking concerns which haven't yet been addressed, and in the meantime it's sucking time/attention/focus away from the DA + security team + other volunteers when they are all focused on a much higher priority thing. Which seems fair enough.

    freelock’s picture

    Every one of the "Blocking concerns" have been addressed, ad nauseum, in several different issues, in several different ways, by several different people. It's like the DA folks are willfully not reading them, sticking their fingers in their ears and going "la la la I can't hear you!" refusing to listen or consider at all.

    Clearly the DA is hostile to Matrix. It's unclear to me why, because for every objection there is a really sound response.

    webchick’s picture

    Just a thought: maybe it's at least in part due to your delivery? ;) I'm usually not super willing to help people who accuse me of sticking my fingers in my ears and saying "la la la I can't hear you!" ;) Tossing an obligatory link to https://www.drupal.org/dcoc here. Remember we're all on the same side here: making Drupal more awesome.

    The situation currently is the DA has clearly stated they do not have bandwidth for this initiative right now. Hence, postponed. I'm really not sure why that's being taken personally.

    There are others, who are not part of the DA, who have stated several concerns. I am really confused about how you can say they've been resolved "ad nauseum," when one of them was "don't pass our data to third parties," and with the DA saying, "we don't have budget/resources to run our own server." That seems pretty well and truly unresolved.

    I think what I would do in your position is continue prototyping, maybe put together a blog post or video or something showing the awesomeness so that when the DA's plate does open back up again, they have something concise to review that's not a 300+ reply issue.

    hestenet’s picture

    @freelock

    I totally appreciate your frustration. I hate being an obstacle. In this case it comes down to a few factors (some of this is reposted from the other issue where we've been talking):

    #2905534-21: Setup a dedicated drupal.org dedicated matrix server

    The ideal outcome for me:

    1. Everyone communicates in the same place.
    2. No one was non-consensually added to a communication medium.

    Unfortunately I'm not sure these two things are compatible- and the community is *not* even close to agreement on this either way. In the meantime I feel morally obligated to be conservative with people's privacy.

    Point number 2 above is a real tough one. I think your suggestion here: #2905534-22: Setup a dedicated drupal.org dedicated matrix server (i.e: Do this only on the biggest public channels, and with a Topic warning set)... is a good one. But I'm not sure that actually meets the concerns people have been raising (I hope they'll chime in to raise their concerns with that solution).

    If we solved:

    • Impersonation
    • Privacy
    • Non-consensual participation ** this is the primary concern that doesn't also apply to IRC/Slack/anything else

    ... in ways that the people who raised those concerns agreed solved them..... then we're still stuck needing to find DA budget and resources to spin up and start managing another server. I don't think I can get approval for that right now.... but per @webchick's point, maybe those things can be hashed out..

    If they do remain unresolved or contentious... I do have to say that my default stance will continue to be deferring to privacy in the current climate.

    Greg Boggs’s picture

    @webchick thanks for all your effort getting this issue updated and for providing some focus on the current status of Matrix bridges. It's a hard thing that you're doing for the community to work on these communications with everyone. And I really appreciate your time and energy. I know a lot of folks are eager to have free software chat and free software clients for Slack, so this is a difficult issue for a lot of people.

    freelock’s picture

    If we solved:

    Impersonation

    Matrix provides a level of verification not possible in IRC or Slack -- right down to device fingerprints (needed to support e2e encryption). The Matrix solution to impersonation is disambiguation -- if there is more than one user with the same display name in a room, show enough information that it's clear who is who. This is not easily defeated.

    We already know Slack has a problem with impersonation -- it's happened before, and required admin control to address. IRC is a wild west, if the room doesn't require registered nicks... and users need to know to register their nick to avoid impersonation there.

    Matrix provides the same kinds of kicks/bans/ignore options as IRC, at least as far as the Drupal channels have needed to go.

    Privacy

    Nothing precludes people going to a private room. These are public chats, and at least some of the time, have had public logs. What is the issue here?

    Non-consensual participation ** this is the primary concern that doesn't also apply to IRC/Slack/anything else

    Again, this seems like a weird constraint for a public room meant to provide support to the public. If a team wants to have a single channel that is not bridged anywhere, for private team communications, nothing precludes that, nobody is arguing that all communications should be public. We're just trying to make it easier for people to find and use *PUBLIC* chat rooms. Why should anyone care what client the person on the other end wants to use?

    This is like saying "I'm not going to send email to you because you use Outlook." My email might end up on an Exchange server I don't control -- horrors! Gmail is the worst -- Google can see all your email, so I'm not going to email anybody with a Gmail account. That's exactly what's being said here, just substitute email for chat to see how ridiculous this is.

    ... in ways that the people who raised those concerns agreed solved them.....

    Well, that is the issue here. The people who have raised these concerns have all gone silent when their concerns have been addressed. Thus the frustrations.

    then we're still stuck needing to find DA budget and resources to spin up and start managing another server.

    Not necessarily. The first step of the solution involves no DA budget, no resources, no need to manage another server. That's only needed if the DA wants to offer "@drupal.org" identities or room aliases -- but that can easily be added in the future, or not at all, without diminishing the usefulness of the bridges we're after.

    The only thing we need to complete these bridges is a Slack admin to grant permission to add them. It's a couple minute process, for each room, and it's done. And the DA can move on to other issues, not need to be involved at all until after the rest of the infrastructure issues are dealt with -- drupal.org Matrix servers are a "nice-to-have" but in no way essential to solving the chat fragmentation issue.

    webchick’s picture

    My understanding is the blocking concerns there is that Drupal's Slack community has some community norms, like:

    1. All participants active in a channel/discussion are visible to all other participants. (IRC also has this expectation.)
    2. There is only one "webchick" or "freelock" or whoever on the network. (IRC also has this expectation.)
    3. All participants were required to register and thus can be tied back to a valid email address to help temper abuse.
    4. All participants were required to adhere to the Code of Conduct in order to participate.

    My understanding from talking to folks there with concerns is that:

    1. With a bridging solution like Matrix, participants coming from bridges are only visible if they actively write in-channel, meaning there could be dozens of unknown lurkers at any given time, which can have a "chilling effect" on discussion.
    2. Because IRC doesn't require registration, bridging from IRC means someone could trivially easily create a rogue "freelock" account (or probably not freelock, since I'm sure your nickname is registered on IRC, but pick some other contributor who's been out of the community for awhile like @marvil07) and impersonate you in Slack, and there'd be no way for anyone—even Slack admins—to tell it wasn't them.
    3. Slack folks view registration as a pro of their service, not a con. IRC does not require registration. This makes these two fundamentally incompatible.
    4. There is also no way on IRC to enforce DCoC adoption. This makes these two also fundamentally incompatible.

    Are there solutions that have been presented for these that have gotten missed along the way?

    freelock’s picture

    @webchick ah, thanks, finally some clear explanation of the concerns people still have after all the dialog -- this is what's been missing:

    Slack folks view registration as a pro of their service, not a con. IRC does not require registration. This makes these two fundamentally incompatible.
    There is also no way on IRC to enforce DCoC adoption. This makes these two also fundamentally incompatible.

    This makes it sound like it's not Matrix that is the problem the DA has -- it's IRC.

    And yes, I agree, this is a fundamental issue with IRC, that's probably not possible to solve. There's no way I know to have a public IRC channel and put the DCoC in front as a gate -- IRC simply isn't that sophisticated.

    So if these are the concerns, why not at least leave the Matrix/IRC bridges in place? Nobody has raised any valid concerns about that bridge -- why remove it? From your first list, 1 and 2 are not an issue with the IRC bridge -- they are only issues with the Slack bridge. 3 and 4 are not possible on IRC already. And from your second list, these are all issues you seem to have with IRC, none of them apply to Matrix or the IRC bridge. (FWIW, Matrix can easily address all 4 items from your second list, if bridges aren't involved).

    webchick’s picture

    Yay, glad we're speaking the same language! :D Sorry on my end; I don't know really anything about Matrix and I wasn't behind Drupal Slack, so I'm trying to "bridge" (ha!) two worlds, and sometimes failing badly at it. :P

    So, pardon my further ignorance, but what is the benefit of a Matrix/IRC bridge if it doesn't also connect to Slack (where, once again, the vast, vast majority of people have already moved)? Wasn't the point of exploring Matrix to fix the regression of the community chatting in two places? Or would this basically be to give IRC users some of the additional benefits Matrix has, like groups functionality and additional security?

    Greg Boggs’s picture

    One of the biggest features for me would be being able to use a better, open-source client to access Slack. It's possible I can get the RIOT client connected to Drupal Slack through gateways: https://drupal.slack.com/account/gateways. So, that might be a win even without bridging. But, with the bridge, all I had to do to connect to Slack was click a RIOT link and it just worked.

    freelock’s picture

    So, pardon my further ignorance, but what is the benefit of a Matrix/IRC bridge if it doesn't also connect to Slack (where, once again, the vast, vast majority of people have already moved)?

    Well, a Matrix/IRC bridge basically allows us to use a rich, Slack-like interface with normal IRC -- and interact with people who still use IRC. Obviously if it's not bridged to Slack, we're not part of the conversations on Slack -- but at least we are on the conversations on IRC.

    Wasn't the point of exploring Matrix to fix the regression of the community chatting in two places?

    Well, yes, that's one part of it.

    My shop has been using Matrix for 2 years -- it's our core platform. Many other shops have chosen Slack, but we (obviously) prefer to use open source, self-hosted solutions. And one of the big benefits of Matrix is that they have done a lot more work on bridging to other networks than anyone else -- their vision is to make "chat" universal, like email, instead of silos like the early days of email where AOL users could only mail other AOL users, Compuserve users only interact with other Compuserve, etc.

    Matrix is trying to be the SMTP protocol for universal chat.

    But if having mandatory registration and DCOC acceptance is a requirement, this obviously is inherently at odds with a broader open conversation. It's also a (huge!) barrier to casual questions from new Drupal users, so I question whether the Drupal Association wants to even have an easily reachable place to offer this kind of support -- or if they want to continue to only have a closed, restricted conversation among people who are ok with Slack.

    Or would this basically be to give IRC users some of the additional benefits Matrix has, like groups functionality and additional security?

    It allows IRC users to continue using IRC without any change whatsoever. And it allows those of us who prefer Matrix to post code snippets, screenshots, have video/audio conversations, embed widgets, use a variety of other bots, all while degrading gracefully to IRC. If we hadn't said we were using Matrix, IRC users would never know the difference -- they would just see the automatic paste-binning the bridge does, links to images/videos/etc and miss out on the richer experience.

    Bottom line here: is the DA trying to be inclusive to the broader community, or exclusive to those who are willing to use Slack? (there's probably a lot more of us than you realize...)

    freelock’s picture

    We can certainly create bot-controlled Matrix rooms to bridge to Slack, and basically make the bot enforce a similar signup workflow before inviting users to a room that requires invitations. The membership list sync'ing is limited by the current Slack API that the bridge uses, but otherwise this could address all the other concerns expressed here -- if we don't then bridge that room to IRC.

    I'd be willing to write up such a registration bot and include as a submodule or related module in https://www.drupal.org/project/matrix_api , if this is deemed necessary, so that the list of registrants can be managed in a Drupal 8 site...

    This approach doesn't solve the fragmentation issue, but it would at least allow people to use a single open source client in all the conversation locations, while preserving Slack and IRC room silos as they are.

    webchick’s picture

    Bottom line here: is the DA trying to be inclusive to the broader community, or exclusive to those who are willing to use Slack? (there's probably a lot more of us than you realize...)

    This question misses the mark, IMO. The DA / security team isn't in the chat business at all right now (both IRC and Slack grew organically from community pushes, and both are maintained by 3rd parties). Them wanting to stay this way is one of the reasons this issue is postponed right now.

    So it sounds like, among other benefits, Matrix can be like a fancier and more feature-rich UI for IRC. So can you explain why does that need the DA or security team to do anything? Why can't someone who wants a fancier UI for IRC use matrix.org/riot.im/wahtever on an individual basis? If it's a matter of a trusted third-party, could they connect to Freenode's Matrix server that was previously mentioned, or..?

    freelock’s picture

    This question misses the mark, IMO. The DA / security team isn't in the chat business at all right now (both IRC and Slack grew organically from community pushes, and both are maintained by 3rd parties).

    Well, if the DA wants to stay out of it, that's fine. At some later date when appropriate we can all revisit an "official" chat service, and by that point Matrix might be the most compelling option anyway...

    But if it's not the DA opposing bridging to slack, who is? We've already bridged much of IRC, and there are some country groups already bridged into Slack.

    Personally, I'd just like to participate in the Slack conversations without having to run Slack. And all it takes is an admin on a "maintained by 3rd parties" slack room to approve two webhooks. (Something that can easily be revoked if it proved to be a problem).

    As part of a growing group of people on Matrix that "grew organically from community pushes, and ... are maintained by 3rd parties" we're just asking to be able to participate on a free, open source client instead of having to use a proprietary SaaS to be part of the larger conversation.

    So can you explain why does that need the DA or security team to do anything?

    We don't need anything for the IRC bridge -- just that it not be removed. And if you're not controlling the Slack access, then we don't need anything from you at all.

    We were looking to expand this to Slack, and bridge the communications. If IRC and Slack are fundamentally at odds with each other, then it sounds like this is a non-starter.

    Why can't someone who wants a fancier UI for IRC use matrix.org/riot.im/wahtever on an individual basis?

    We do already. We just don't want that taken away.

    If it's a matter of a trusted third-party, could they connect to Freenode's Matrix server that was previously mentioned, or..?

    Freenode doesn't have a Matrix server -- not sure where that misinformation came from. Matrix.org works closely with Freenode staff to make sure the > 100,000 bridged matrix users meets Freenode's standards for privacy, security, all the concerns being raised here. And by all accounts, it's a very good relationship between Matrix and Freenode.

    webchick’s picture

    But if it's not the DA opposing bridging to slack, who is?

    It's members of the current Slack Admin team, several of whom have posted in this thread and others with their concerns. I think they've mostly gone quiet at this point because they're feeling repeatedly dismissed and unheard. :\ Sounds like you feel the same way. So let's all try and work on our communication a bit, here; this really doesn't need to be an emotional discussion, and it's really just getting in the way of people understanding one another.

    Personally, I'd just like to participate in the Slack conversations without having to run Slack. And all it takes is an admin on a "maintained by 3rd parties" slack room to approve two webhooks. (Something that can easily be revoked if it proved to be a problem).

    As part of a growing group of people on Matrix that "grew organically from community pushes, and ... are maintained by 3rd parties" we're just asking to be able to participate on a free, open source client instead of having to use a proprietary SaaS to be part of the larger conversation.

    Right, and they are just asking for their blocking concerns to be resolved prior to facilitating this. But it sounds like at least some of them may not be resolvable?

    Why can't someone who wants a fancier UI for IRC use matrix.org/riot.im/wahtever on an individual basis?

    We do already. We just don't want that taken away.

    Sorry, I'm confused again. If a Matrix/IRC bridge can exist without the DA / sec team / Slack admins needing to do anything, what exactly is threatening to get "taken away" here?

    And ok, sorry about my misunderstanding of Freenode/Matrix. I thought that's what @ricardoamaro was saying in #2490332-297: Evaluate whether to replace drupal IRC channels with another communication medium.

    davidhernandez’s picture

    I'll say again (Though maybe it hasnt been said in this particular issue. There are multiple gong on.) you can connect to Slack through an IRC client. You don't have to use Slack's own app. If that is someone's main concern.

    lpalgarvio’s picture

    Sorry for interrupting this debate, and for posting this again, but this deserves attention.

    @webchick and dear all IRC admins and Infra team,

    Our #drupal-pt has been affected by this change and it can not be.
    You see, it is oversee, ran and managed solely by the independent Drupal Portugal Community, and the ADP - Associação Drupal Portugal, non-profit organization registered and running in Portugal, which also founded all the Drupal Portugal channels across different platforms - channels which you can consult here and here.

    This has happened because in the past we have decided together with the Drupal Association many years ago, in 2010 or 2011, to allow in the #drupal-pt channel the drupalircowner user, and set it as the owner, in order to Protect our IRC channel from misuse and abandonment.

    You have however decided to also block (ban) the bridge in our #drupal-pt channel, as well as in other community channels, such as #drupal-be, #drupal-in, #drupal-nl and others.

    It is causing us harm and grief.
    We kindly ask you to unblock the bridges in such community channels, as they are run independently.

    Also, if the action was taken against official channels, why were we target as well, and why weren't we warned?

    Thanks

    rodrigoaguilera’s picture

    Removing the IRC-Matrix bridge feels like very hostile movement against matrix without very solid reasoning.
    Now I have to search for an alternative IRC client :(

    freelock’s picture

    FileSize
    34.17 KB

    If it's Slack admins who don't want to be bridged, why did I just get kicked and banned from several Drupal Freenode rooms?

    Has there been a single instance of abuse from Matrix in IRC? Why this drastic, hostile measure? It's very much going to reduce my participation in Drupal, that's for sure -- you've just banned my IRC client.

    @webchick the threat was just made real.
    Banned

    This is a case of the IRC admins banning the Matrix bridge, blocking us from participating in the community, because of security/privacy concerns that the Slack channels have? Ones that are already worse in IRC itself than they are in Matrix?

    Sheesh. Utterly ridiculous.

    If the problem is IRC is not compatible with Slack, why is IRC banning Matrix? Can anyone point to an example where the Matrix/IRC bridge has been any kind of problem?

    hestenet’s picture

    @lpalgarvio et. al-

    I'm sorry this is proving disruptive to your community. We are trying to find an appropriate response. The issue being - in none of these issues was Matrix bridging ever approved as a permanent solution for any official or semi-official drupal-# channel.

    It *was* approved in this issue #2902791: Bridge drupal-in IRC channel with #drupal-in:matrix.org as a *test* for the possibility of bridging. As far as I'm aware no one ever opened issues or asked about bridging any other channels.

    At the same time, the #drupal-pt clearly took this idea and ran with it and are now largely dependent on it, so this is obviously disruptive...

    I'm very sorry about this disruption, but given the unresolved issues we chose to decommission this integration until or unless we can resolve those concerns. Those issues of privacy/impersonation/consent still trump convenience or disruption.

    lpalgarvio’s picture

    I've talked with timplunkett over Riot <-> IRC. The conversation wasn't pleasant, as i rushed in, very upset with this matter, asking to talk with the people responsible for this. I'll not comment on how he responded, which i frankly don't care if it was correct or not, but on the facts.

    - timplunkett refuses responsibility.
    - denies that he is an IRC admin.
    - admits he is a Slack admin.

    Now I see on IRC:
    - timplunkett nick changing to timplunkett[m] (Matrix alias)
    - is an admin on many IRC channels, like #drupal (+Aeiortv, since 5+ years)
    - probably is a Slack admin as he admits.

    Probably also has access to the drupalircowner user, which is one of the only users to have op access in #drupal-pt.

    Am I the only one who sees conflict of interest? Was I lied to?

    The Bridges are still broken for the Community channels.

    freelock’s picture

    Those issues of privacy/impersonation/consent still trump convenience or disruption.

    But those are issues with the Slack bridge, not the IRC bridge!

    I've been using the Matrix IRC bridge for 2 years now in a dozen Drupal rooms, in exactly the same way as many users use bouncers, and I'm certainly not the only one.

    Now, I'm effectively disconnected from IRC, at least the ones that have the drupalircowner set. (Several others are fine).

    Where are the negative results from this "test" that have led you to intentionally break communications channels some people have been using for years? A bunch of hypothetical fears and irrationality here. No wonder the Drupal community is fragmenting -- with administrators actively fighting to shut down communication channels.

    lpalgarvio’s picture

    @hestenet

    The Drupal Portugal channels exist in Matrix since 09/Jan/2017, bridged the same week, and the Telegram channels exist for far longer, and have been bridged successfully on 22/Aug/2016.

    Both are now broken because Telegram interfaces with IRC, and now people are talking to walls.

    They both predate ANY decision and were implemented solely by us, and demonstrated to others to show the potential.

    Why would the admins assume that these channels are dependant of DA? Which others have been affected?

    We want the bridges back on for our community channel.

    hestenet’s picture

    @lpalgarvio - Just to be clear here @timplunkett is not responsible for these changes or this decision, though he was one of many people consulted, and one of many people concerned about the issues mentioned in #2490332-307: Evaluate whether to replace drupal IRC channels with another communication medium

    I will say this again. Our passion about choice of chat clients =/= forest fire. The community is not burning down over this. We need to be very careful, deliberate, and respectful when making new technical choices and integrations.

    Right now, we have not achieved the appropriate cross-community consensus to implement bridging in a way that satisfies the concerns in the comment I linked to above. There has also been a lot of running roughshod over peoples concerns and just implementing new tools without trying to build consensus, in the hopes that it would just build organic momentum. And admittedly that is a strategy that has worked for other tools. For this tool, where a person's words are bridged with or without their opt-in, that technique has not worked and in fact, backfired on concerned parties willingness to consider this solution.

    @freelock - are you currently prevented from using Matrix just as a client? (does it have that capability?) Or does it *only* work as a client by bridging channels? (Edit-to-add: I don't know how you were using this for 2 years if it required freenode admins to set up the bridge, which should have required consensus from the drupal IRC admins?)

    webchick’s picture

    Hm? Only the lack of adoption of the DCoC and lack of registration were Slack-specific concerns.

    Impersonation is one of the biggest and not satisfactorily addressed, from anything I've read nor what I've been told. Apparently thanks to @mlhess testing, there's a webchick running around on riot/matrix despite me never logging into one of those places. While Matrix (apparently) provides additional info to help people suss out that that's not me, IRC doesn't. I'm just "webchick[m]". That's what we call in core a "critical bug" and it blocks release, as it should here.

    Consent is also a huge one and not addressed. While people probably are less ideologically concerned with their information from IRC landing in Matrix vs. landing in Slack or a similar commercial entity, there's no way for them to know that this is happening on their behalf. While it's been argued this is no different than an IRC bouncer, IRC bouncers are fairly common. Bridges to entirely different chat platforms are not. And the onus is on this team to prove they have consent; "well no one complained about something they didn't realize" is not a valid defense. :)

    @lpalgarvio unfounded accusations and conspiracies against community members are not tolerated. If you have an issue with the way someone treated you, the CWG can be contacted to help mediate.

    lpalgarvio’s picture

    @webchick I'm not here for any of that, and I don't want to seek any issues with tim, so I'm just going to refrain from contacting tim.

    Since this decision doesn't look to be reversed any time soon, neither the Drupal Portugal community channel seems to be going to be fixed by any of you any time soon either, I've opened a new ticket whereby I ask for the delivery of the founding status of the channel to our @Druplbot user.

    https://www.drupal.org/node/2906035

    wturrell’s picture

    This sentence irritated me a bit:

    "that's [Slack] where 90% of the Drupal community is today, and they have no intention of moving to anything else."

    Firstly, it depends how you measure it obviously, but I'd suggest most of the overall Drupal "community" rarely if ever use chat at all (myself included), and imho that's a good thing. Chat being popular doesn't necessarily mean people will be more productive or any nicer to one another.
    As for the second bit, who can predict what they'll do? Who knows if Slack will be better/worse/good/evil/still exist in five years.

    Also, does it even matter if Drupal has more than one chat platform? Other than the issue queues (which is where decisions are supposed to happen) and other bits of Drupal.org, most of the project is fragmented. Arguably, all that matters is a page with a canonical, up to date record of where to find certain groups of people, and the continued ability for individuals to specify on profile pages etc. where they can be found.

    Imho, the key concern for end users is surely not the platform but the ability to use a client that broadly matches their personal preference (whether it's something minimal and text based, something they can run in a web browser, or a mobile phone app, a client that supports audio and video chat, or something for those people for whom proper language is apparently no longer good enough and who can only communicate via Emoji and animated GIFs...) Plus basic security, identity verification etc.

    Matrix was sounding very promising when I last contributed to this thread, especially given its non-commercial nature and choice of clients.

    Also, we can't keep rerunning this conversation just because people coming to it fresh haven't made an effort to read the previous comments (many of which are detailed).

    freelock’s picture

    @hestenet I am blocked from many Drupal channels right now because of this. Matrix does not talk IRC directly, its bridge does.

    There are two types of IRC bridges, "Plumbed" which require an IRC op, and permits some configuration changes on the Matrix side of the bridge, and "Portal" which do not -- any Freenode channel may be joined and it auto creates a Matrix room with restricted settings that do not permit past history visibility or guest access. Both have been kicked as a result of this action.

    @webchick what's to stop anyone from impersonating you on any of the hundreds of other social media systems? The world's a much bigger place than just the Drupal chat rooms. Mastodon now allows anyone to run their own Twitter-like service, and use any display name they want. There are plenty of naming collisions in the real world -- the best you can hope for is to make a clear disambiguation policy, like Matrix does -- or go hole up in your own silo where you don't have to talk to any outsider.

    For Matrix in particular, yes there can be many webchicks. However, you can just say "I'm the one that is @webchick:drupal.org" and nobody can spoof that, if you're registered on the Drupal.org server. It's much like email, except that nobody can spoof your 'from' address/Matrix id. (At least not without hacking your client somehow). For the IRC bridge, if you have registered webchick on Freenode, you can't use that nick from Matrix without authenticating to Nickserv. (I'm just "freelock" on IRC, not "freelock[m]", and my Matrix account is registered with Freenode's nickserv like anybody else with a registered nick.)

    Regarding consent, isn't a notice in the channel topic sufficient? Who doesn't read that when entering a room? And Matrix rooms only show history to people who have been present in the room at the time of a particular message, unless an admin explicitly configures otherwise (which can't happen in a "portal" room).

    But, more to the point: If the bridge was only "a test", where is the transparency around the results of this test? You all have given mysterious hand wavy excuses for shutting it down -- where is there an incident that could not be handled with a normal kick or ban? Where is there an example of the Matrix bridge causing an abuse issue that could not be done even easier from IRC? Where is there an incident of something private becoming public due to the bridge (in a public room of all places!)

    Can anyone provide a clear, understandable, specific example that came out of the test other than "somebody registered my name" that is reason enough to disrupt a bunch of country team's chosen communications, and a lot of other users who think chat should be universal and not a bunch of silos requiring everybody to load up a bunch of different apps to talk to somebody?

    frob’s picture

    I will say this again. Our passion about choice of chat clients =/= forest fire. The community is not burning down over this.

    One of our communities is burning down. RE: #2906035: Return the #drupal-pt channel to the community the dismantling of the bridge has segmented this community. Please reinstate the bridge for their channel. Also here.

    markhalliwell’s picture

    The DA / security team isn't in the chat business at all right now

    That hasn't been true for years.

    Per https://www.drupal.org/irc/adding-channel

    5. Please file an infrastructure issue so a member of the infrastructure team can acknowledge the drupalircowner founder transfer.

    The DA/infra has always been the "end point" for all IRC related things. Yes, there are admins (ops), but the DA/infra "own" most of the #drupal-* related channels (drupalircowner).

    Never mind the fairly recent Druplicon -> Drupalbot drama and now the explicit "banning" of Matrix bridges ^^^

    One cannot claim to have no stake in the matter and then simply impose a unilateral decision that affects our entire community like this and say they're "not in the business"... DA/infra is very much in the center of it all.

    This, amongst many others, is part of the reason why this whole issue exists in the first place:

    Finding a better solution for everyone, even for DA/infra.

    hestenet’s picture

    Hello everyone, I can appreciate here that many people are very frustrated and are doing their best right now to communicate in a respectful way. I very much appreciate that and encourage us all to continue that to the best of our ability.

    There are two additional elements here that I think have made this more contentious and more unexpectedly disruptive than I think the IRC admins in general and other concerned parties thought it would be.

    1. Per the freenode policy of name-spacing, any channel named with the drupal-* policy is the domain of the current set of Drupal IRC admins.
    2. It is expected that the Drupal IRC admins will enforce consistent rules across all of the drupal-* channels so that the community knows what to expect from these channels. drupalircowner is added to channels in that namespace in order to accomplish that.

    Until now that's mostly been a point of convenience and consistency - and not really contentious because it simply helped all these local communities manage those communities in a consistent way, with help from the existing irc admins, and for any new users to join those channels to understand that anything they join in the drupal-* namespace follows the same namespace.

    In this case---- bridging for one of these channels was enabled almost as soon as the channel was created, without the knowledge of the majority of IRC admins.

    To be completely clear - until 2 days ago my understanding was that there was no bridging set up until the request for #drupal-in in the issue queues. I have only recently learned that it was set up in many other channels without issues being opened, and without consultation of the majority of IRC admins.

    ^^ This kind of situation is what has lead to other communities banning bridging in official channels, like the ##techsupport community, for example.

    That said... it is not the fault of the majority of people in the #drupal-pt community who used these bridging solutions. They had no way of knowing they were set up without the knowledge of most of the IRC admin group. And the disruption they are experiencing is real.

    I propose the following:

    1. The 'plumbed' style of bridging will remain turned off, for all of the reasons of privacy/security/consent/etc that were outlined above.
    2. #drupal-pt (and anyone else!) will be allowed to do the limited 'portal' type of bridging that allows matrix to be used as a client.
    3. Users who use this as a client will need to identify - i.e: it won't use whoever[m]

    TLDR - We'd like to put in place configuration to allow Matrix to work as a IRC client/bouncer, to resolve the disruption this caused to the #drupal-pt community. It will not allow any of the additional features that matrix provides that could create 'plumbed' style bridges, which is where all the unresolved concerns of this issue are hung up.

    These changes will hopefully be in place by Tuesday afternoon, pending time of both IRC and Matrix admins.

    @freelock, @lpalgarvio, et al -- I hope this resolves the immediate disruption? At the very least it should let us slow down and stop making panic decisions.

    In the medium to long term, if this solution does not work for the #drupal-pt community we can forward the existing drupal-pt channel to a new channel completely in the Portugal community's control, not overseen by us. However, I would like to keep the drupal-* namespace consistent, just so we can keep on top of managing it.

    freelock’s picture

    @hestenet thank you for listening and taking our concerns seriously. Using the "portal" bridge only is fine by me, and makes it so I can actually participate in IRC, instead of being effectively banned. I was using it happily and effectively for the past 2 years.

    The only reason I got behind the efforts to "plumb" the bridges in the first place is because I think open source projects should use open source infrastructure, and this was an easy first step to bring the community back together again -- a community that has been ruptured by the introduction of Slack. While there may be a bunch of people using Slack, there's a lot of us for which that is not an acceptable solution, and Matrix seems like an easy solution to this problem. I still think that's the case, and will continue to advocate for that... but for the time being, restoring at least the portal bridge works for me.

    mlhess’s picture

    +1 to the above, thank you for putting this into words.

    The work to do that is being tracked in #2906243: Allow matrix users to use matrix as an IRC bouncer client

    lpalgarvio’s picture

    thank you for the proposed resolution hestenet.
    I've commented in the drupal-pt issue, without reading fully this thread.

    anyways, i can't comment further at this moment, but i might do later or tomorrow.

    hestenet’s picture

    No problem @lpalgarvio - I know you're very passionate about protecting your local community. :)

    ciss’s picture

    ...and yet, 3800 people are actively using it every day, which is an order of magnitude more than use IRC.

    Do we have the means to quantify active users (or user activity) across the Drupal channels on Slack? 3800 users seems somewhat high - given the activity i saw I would assume that number includes any user that has joined one of these channels at least once at some time (without signing out afterwards).

    frob’s picture

    I am not sure where the 3800 number came from. My view of analytics show it much much much lower. The highest loggedin users in a day is 843 on August 30th. It seems to float in the high to mid 600 to low 700 mostly during the week. With that number dropping to around 200 for users actually sending messages.

    That is unless I am looking at the wrong number. These look like the number of users sending messages on any given day.

    davidhernandez’s picture

    That is daily activity, though I don't know what counts as activity. Number of registered users is 4550.

    frob’s picture

    The more number of people sending messages floats around 200. Is there any way to get this stat from IRC? This is the general room of slack that I got these numbers from.

    The total number of nicks in #drupal right now is 278, that is that I can see.

    The important thing is to get actual comparable stats. So to compare that 4550 we would need to know how many people ever logged onto IRC ever. That isn't a valuable comparison and is likely impossible to get.

    For example, as soon as I heard there was a drupal slack I parked my nick. I never had any intention of using slack, but I wanted to make sure no one else took my nick. This means that I am counted among that 4550 number, but I don't use slack.

    freelock’s picture

    470,482 messages sent, and stored by Slack. Of which 460,482 of those are only accessible by a third party (internal Slack admins), not even viewable by Drupal admins. Sad.

    Next I wonder if it will shut down access when the number of registered users hits 5000, like it did for FreeCodeCamp.

    But by far the most complete essay detailing why Slack is so bad for open source is here: http://www.pdfernhout.net/reasons-not-to-use-slack-for-free-software-dev... . Very much worth a read. And it even mentions this very Drupal issue. Choice quote here:

    A free software project like WordPress choosing to abandon IRC and choose Slack for free software developer chat sends a message that free software is not good enough for regular communications and is not worth investing in to improve to meet whatever needs the proprietary software meets. That has a negative impact of the future of free software projects including ironically even WordPress.

    ciss’s picture

    Is there any way to get this stat from IRC?

    netsplit.de frequently logs joined users (although for whatever reason #drupal is missing). From personal experience the amount of idling users on IRC is very high. To get reliable stats I can only think of two options:

    • If someone with mostly uninterrupted logs for a major number of channels is willing to run a script across those logs, we could extract some past statistics from that.
    • Drupalbot could be repurposed to track activity by message frequency. But given the current privacy concerns I doubt we will be able to track active users, as this will require tracking of user names (or hashes of those).

    I agree that some hard numbers would help to get a better picture of the current state of fragmentation. One of the questions I consider most important at present is where new users currently try to get in touch with the community:

    • For less technical users I would imagine that Slack might be the first choice. It would be great if we could get some stats on new joins on Slack.
    • For users that come from other systems/communities (especially those that use Freenode as a platform), it's just a matter of joining the respective Drupal channels. But personally I haven't seen a lot of new faces lately, so I imagine that these might end up in Slack as well.

    I have no idea where Matrix fits in. Someone else will have to fill in those blanks.

    geerlingguy’s picture

    There has also been a lot of running roughshod over peoples concerns and just implementing new tools without trying to build consensus, in the hopes that it would just build organic momentum.

    Not sure if you were intending this to be a dig at the Matrix bridging, the Slack community, or both... but I just wanted to note that I'm one of the 4,000+ lurkers in Slack, not because I want to be, but because maybe 1/3 of the time someone wants to ping me on a contrib issue, it's annoyingly inside Slack.

    Slack feels great for smaller, focused communities (e.g. Regional user groups, small office groups), but one of the best aspects of IRC is that through using it for #drupal-*, I also found tons of other great OSS communities like #docker, #ansible, and many others (all one /join away). It would be a shame to jump ship to Drupal Slack island.

    ricardoamaro’s picture

    Issue summary: View changes
    ricardoamaro’s picture

    Updated the links so they point to the #freenode native rooms instead of the ones using the IRC integration.

    dqd’s picture

    @webchick

    before we hit #300

    I feel with you,
    so I got a rhyme for you:

    it's too late ...
    it is a quite long debate
    It seems to be Drupals fate
    already hitting number #348 ...

    Sorry, not my native tongue :) (just a little joke for the weekend) ... Wow, we are already on page 2 of comments? The discussion becomes absurd. There are percieved more users being in the chat discussion than actually being in the chats...o.O

    but one of the best aspects of IRC is that through using it for #drupal-*, I also found tons of other great OSS communities like #docker, #ansible, and many others (all one /join away). It would be a shame to jump ship to Drupal Slack island.

    @geerlingguy Good point.

    betz’s picture

    We had a Chat BOF here at the Belgium DrupalCamp yesterday.
    Joined where people behind the rocket.chat and matrix initiatives.

    One conclusion was to work bottom up.
    Get the local communities bridged on different platforms.

    jbitdrop’s picture

    @betz, can you elaborate a little bit more on "bottom up"? Do I misapprehend it? It reads kind of "Local communities would like to do their own thing"... Shouldn't there be a consens on all levels before changing anything on local communities? How many people of how many local communities have agreed on that (approximately)

    @diqidoq: heh. :) yeah some more relaxing at this issue could be healthy ...

    @webchick: From what I understand of your comment,

    Impersonation is one of the biggest and not satisfactorily addressed, from anything I've read nor what I've been told. Apparently thanks to @mlhess testing, there's a webchick running around on riot/matrix despite me never logging into one of those places.

    We have no real mechanism yet to force unique Drupal user identities on the other chat solutions to prevent misuse of Drupal nick names? Doesn't this also affect the logs? This would also make Drupalbot messages and commands like seen userxxx useless. Doesn't it?

    betz’s picture

    @jbitdrop yes, bottom up.
    Local communities are unrelated to the main infrastructure. And offcoarse we need permission to do so, but that seems easier to reach for now.
    Many communities are bridged already...

    dqd’s picture

    @betz: I see some issues raising here. As already stated: What about the Drupal bots? And what about the stated questions regarding unique user identity, security and chat logs? I see some clutter coming up here soon and this can possibly seperate the communities a lot. How does these bridges work? Could somebody else try to be me there? And can I see the bridged users from my POV when I am logged in on IRC only, but they are logged in on rocket only? Or only the other way around? I am still curious if this will be a future prooved effort.

    Greg Boggs’s picture

    That's a lot of questions in a paragraph, but I think I know some answers for you so...

    If we set up bridging, then:

    • the IRC bots will be able to connect to Slack through the bridge. But only if we wanted them to.
    • security would increase in matrix with a riot client only because they support open-source end-to-end encryption. Security in Slack would still be entirely dependent on Slack which we know has some pretty serious holes with file uploads.
    • Chat logs work similar to Slack or IRC bot logs. Logs of public chats only.
    • Someone else can try to be you on any chat. It's clear from the name that it's not you. If you want to prevent someone on matrix using a Matrix handle, you register it just like you do for Slack and IRC.
    • If you log into IRC, you can see the bridged users who chat, but you can't see the Slack users chatting.

    To reiterate, some of the bigger concerns expressed are:

    1. Bridged users don't display in Slack until they speak. For big channels, this is not a big deal but for smaller ones, it's quite strange.
    2. If bridges are set up, there are now 3 services where you can register a nick: Freenode Matrix and Slack. Currently, we only have 2 places you must register to protect your nick.
    3. A few folks are worried about adding people from Slack to Freenode without express warning to those people.
    4. The Drupal Association staff aren't currently resourced for running Matrix servers.
    5. We don't generally trust the RIOT folks as much as we trust Slack or Freenode.

    freelock’s picture

    Some clarifications re: Greg Boggs's post...

    Chat logs work similar to Slack or IRC bot logs. Logs of public chats only.

    Log visibility is defined per room. Due to an agreement between Matrix and Freenode, the current "Portal" bridges are required to be created by the bridge, and restricted to only show history to people "since they joined the room" and "no guest access" on the Matrix side.

    If a room is "plumbed" with a bridge (which requires IRC ops), these visibility and guest settings may be changed, and also other bridges may be added to the same room (Slack, gitter, etc). Room visibility settings are visible to all Matrix users. Other settings include make all history visible to all registered members, visible to anyone (including guests), or visible to members since they were invited. Changing history visibility only affects visibility of messages sent after the visibility change -- so you cannot make older messages public that were sent when a room only allowed message visibility after a member has joined.

    2. If bridges are set up, there are now 3 services where you can register a nick: Freenode Matrix and Slack. Currently, we only have 2 places you must register to protect your nick.

    Well, not quite. Matrix is decentralized, and there are several thousand "homeservers" already. I run my own Matrix server, as do many of us in this thread. You don't need an account on the matrix.org homeserver, although most people start there. It's much more like email -- you have a domain part and a local part (although the syntax is flipped -- I'm @john:matrix.freelock.com for example). What's more, you have two different things: a "Matrix ID" aka mxid, which is meant to be hidden, cannot be changed or spoofed, and is only shown for disambiguation (unless you go looking for it); and "Display name" which you can set to anything, and there's no restriction saying it needs to be unique within a room or anywhere else.

    For bridging, this depends on the bridge -- from within Matrix you can set your IRC nick with freenode, and register it as usual, doesn't need to have anything to do with your MXID -- it's just like any other IRC client. For Slack, it shows the bot user as the Slack account, and your display name and avatar from Matrix.

    5. We don't generally trust the RIOT folks as much as we trust Slack or Freenode.

    This I really don't understand. Why is Slack considered more trustworthy than Riot? Riot and Matrix has a very public development process, much like Drupal. Every developer is known, you can reach out and talk to them, see all their commits. They have gone through a rigorous third party audit validating their end-to-end encryption. Why on earth would you trust a closed, proprietary shop where you cannot see the source code at all, over a fully open source, fully visible codebase? Do you even know who develops Slack?

    This is the single biggest reason there's a large number of us that think Slack is entirely inappropriate for Drupal, especially when there are multiple compelling open source alternatives.

    Greg Boggs’s picture

    I can't speak for why people trust Slack. If I had to guess, I would say that the Slack brand is well known, it's used by millions of people, and many people are required to use it already for work. So, they are familiar with it. Contrasting Slack which everyone has heard of to Matrix and RIOT which is something they haven't heard of before, the difference is pretty noticeable.

    kevinquillen’s picture

    I would rather have a chat system that has SSO to drupal.org account and optional 2FA, than to not have it. To get that with Slack, the cost would be astronomical.

    At least with Riot/Matrix you can run it in-house and control the rules, whereas Slack could decide to cut our community off whenever it feels like it (this has happened). But I don't see where Riot/Matrix offer SSO/2FA authentication capability (so we know who is who), but perhaps I am looking in the wrong area. I think after all the events of this year, and the importance of security in the days to come, those two things are very important.

    lpalgarvio’s picture

    The Drupal Portugal community is fully bridged again.
    Telegram, Matrix, IRC, Gitter, with RSS feeds from our website and twitter, and notifications from GitHub.

    lpalgarvio’s picture

    A separate channel for association and management related topics is partially bridged as well.

    lpalgarvio’s picture

    Ideally now we would have a full bridge in place between Telegram and Matrix, as well as posting directly from our website to Facebook and Twitter (and no need to get RSS from these) but this will have to wait a little longer.

    We dropped support for Hangouts and Slack. No bridge, no support.

    lpalgarvio’s picture

    We are also moving our data from Google Drive into our git repositories at GitHub, because Google keeps axing and changing their services and terms of services. We will keep it at a minimum or discontinue it completely.

    Our GitHub repositories are also in sync with copies on GitLab, and these are linked to the hosting solution for auto-deployment.

    lpalgarvio’s picture

    Also without any kind of integration at the moment: meetup.com / eventbrite.com, which we rely on for publishing and managing events (with proper registration and payment if required) for small and larger events, such as meetups, days and camps.

    If you are curious:
    - https://github.com/drupalportugal
    - http://drupal-pt.org/pt/participa-na-nossa-comunidade
    - https://www.meetup.com/pt-BR/drupalportugal/

    lpalgarvio’s picture

    dqd’s picture

    So for the protocol another short summary with question mark to all the criteria we should agree on here

    (Most of the discussion participants already follow that, but it can get out focus soon by reading the whole thang, that's why.):

    1. Any chat solution an Open Source development community uses, should be 100% Open Source, correct? Reasons: Philosophy embracing attempt, and better to check for respecting privacy in code.
    2. Any chat solution an Open Source development community uses, should be established and should be known for staying for a loooong time, to make the effort not wasted building on it, correct?
    3. Any chat solution an Open Source development community uses, should be available from any OS or Device in these times. Reasons: The Drupal community grows and grows, and while this is happening the multiple devices market used by one of them is growing too. So there is a big chance, that many community members require to enter the chat rooms one day from Linux, another day from MacOS or Windows, and in between also from Android or iOS devices.
    4. Any chat solution an Open Source development community uses, should not be biased regarding personal preference or personal taste regarding the polished look of the chat or how pleasant they feel using it at the first glance. Correct? This can change any time and has no long term point.

    When we look at this ^ table, then it becomes clear, why this discussion escalated a bit. But we should cheer up on this positively. It also shows off, that many care of chatting with each other for Drupal. That's a good thing. At least for those who care about contact. A large community can become anonymously very fast. We only should follow these steps above and should try to move out all misinformation on protocols etc. and should replace it with useful informations. And sources should be independent, not biased nor from the protocol/client developers itself.

    And last but not least a statement you will tarring and feathering me for: We should not be forced to decide for a not so good solution only because some local communities use them already, sorry. That should not be the most important criterion here. That's why I agree with @jbitdrop on worrying a lil' bit about the "From the bottom up" attempt.

    webchick’s picture

    I think those are all lovely criteria, except the evidence of the community moving en masse to Slack doesn't bear them out. It appears the vast majority of the community cares a lot more about a seamless chat experience than any of those criteria, and since most people are already using Slack within their organizations, putting Drupal Slack just a tab away, Slack is basically going to win here every single time until the tide shifts to something else. :\

    rodrigoaguilera’s picture

    @webchick
    That sounds a bit defeatist.
    Can't Drupal as a free software project help to change that tide?
    If people follow the criteria that you are mentioning is it worth it to develop free software anymore?

    Personally I was introduced to Slack by members of the Drupal community to participate in conversations that only happened in Slack and that happening for a free software community made me sad.

    I read news today about Slack stopping being monolingual and reminded me of Dries and @enzo talking about welcoming non-english speakers and I feel that is another point to be considered.

    I also realized that I lost access all my private messages on Slack for the Drupal team. I feel this only should be one reason to stop bringing new people to Slack. Bridges are a nice transition for that.

    freelock’s picture

    @webchick these are broad assertions that carry with them a bunch of implicit problems.

    except the evidence of the community moving en masse to Slack doesn't bear them out.

    What part of the community are you leaving behind, by moving to Slack? Your most ardent open source advocates. Is that wise for an open source project?

    This is an area Drupal has been hugely better than WordPress, and now you're abandoning those principles, going into a silo, and sharding the community into free vs. non-free. What's next, a bunch of competing modules instead of coming together on best of breed solutions?

    It appears the vast majority of the community cares a lot more about a seamless chat experience than any of those criteria,

    That sounds like a real dig at the UX of chat solutions it sounds like you haven't even tried.

    Slack is far from seamless if you need a separate login for each Slack team, have to do all this switching all the time... if you want seamless, give Riot a try, it can unify all your chat (which is why it's the only chat I use these days).

    and since most people are already using Slack within their organizations

    That's a wildly unsubstantiated argument. Again I wonder, have you asked who you're leaving behind by this decision?

    Slack is basically going to win here every single time until the tide shifts to something else

    Sad. Just sad. We've offered a solution where everybody wins, where people can use their chat platform of choice and not be excluded from the conversation, but the DA has made it clear they prefer tight control on public chats and forcing proprietary solutions down your throat if you want to participate, instead of having an open, inviting, easy way to participate with the broader community.

    webchick’s picture

    • I take a lot of issue with the flawed assertion that because someone is mandated to use Slack for their job means they're any less of an open source advocate. Like, what?
    • The "cost" associated with multiple Slack teams is a one-time cost per team (thereafter it's just clicking a different "tab" similar to IRC), and most Slack users are already comfortable paying this cost because they had to do so for work. Hence, seamless. Using something else requires going up a learning curve, even if it's a small one. Hence, not seamless.
    • I'm making my assertion based on charts like this: https://techcrunch.com/2016/10/20/slunk/. And that was a year ago; it's only exponentially increased since then.
    • No one's forcing proprietary solutions down anyone's throat. People are moving en masse to Slack willingly, on their own, with their job as a "gateway drug," and neither the DA nor anyone else has any control over this migration whatsoever.
    • What the DA is doing is laying down guidelines that help protect the privacy and security of their users. I am having an incredibly difficult time understanding why anyone on earth is anti-this?

    Once again, I'm not pro-"leaving behind" anyone. I'm pro-Free Software. I've dedicated 12 years of my life to churning out GPL code. I contribute on Drupal.org and not GitHub. Etc.

    I'm just. stating. facts. I'm really not sure why some people in this conversation are getting so defensive about facts.

    freelock’s picture

    Wait, what?

    I take a lot of issue with the flawed assertion that because someone is mandated to use Slack for their job means they're any less of an open source advocate. Like, what?

    I don't care what you use for your job. I care about what tools the supposedly open source Drupal community mandates using, to talk with the rest of the community. Two entirely different things.

    The "cost" associated with multiple Slack teams is a one-time cost per team (thereafter it's just clicking a different "tab" similar to IRC), and most Slack users are already comfortable paying this cost because they had to do so for work.

    There are very real costs to using Slack -- and if you're not paying them, who is? At the moment, unless somebody's paying Slack, you're just free-riders on Slack's infrastructure, and Slack has made it quite clear that having huge open source communities free-riding on their infrastructure is nowhere in their business plans. And lots of large communities have had trouble beyond a certain threshold we're fast approaching. Why even go there?

    Matrix, and Freenode, very much have supporting open source communities in their business plans... and Matrix makes it really easy to self-host.

    But... facts? What's the overlap between Slack users and Drupal users? Are you asserting that all Drupal developers have to use Slack for work? Since when? That's news to me.

    There's lots of other silo'd communication platforms out there. Microsoft has one. Atlassian has a new one. Github has one. Facebook has two or three. Google has a dozen.

    Only Matrix is trying to make it possible for you to stay on Slack, or whatever silo you choose, and communicate with people in other silos.

    No one's forcing proprietary solutions down anyone's throat. People are moving en masse to Slack willingly, on their own, with their job as a "gateway drug," and neither the DA nor anyone else has any control over this migration whatsoever.

    I completely disagree. By blocking bridges to other chat platforms, the DA is very much mandating and asserting control over the Drupal chat infrastructure. Just ask the Drupal Portugal folks whether they have control, or you do. And thus you're acting as protectionists, preventing the open exchange of ideas across platforms, and blessing the conversations happening on Slack to the detriment of all other platforms.

    You (the DA) have taken a stand here, like it or not, while pretending to have no responsibility whatsoever. Please.

    What the DA is doing is laying down guidelines that help protect the privacy and security of their users. I am having an incredibly difficult time understanding why anyone on earth is anti-this?

    I have yet to see how privacy and security is compromised in any way by adding bridges to what are supposed to be public rooms. There is no leak of email addresses, only the IRC nicks or Slack usernames. These are supposed to be public forums, right? Anybody can still create private rooms wherever they want, nobody's trying to stop that. The bridges don't bridge all of Slack -- only designated rooms. Bans and kicks can still be employed to deal with abuse. Impersonation seems to be the big concern, and yet there can be/has already been impersonation on Slack and IRC too -- Matrix does not make this problem worse.

    Once again, I'm not pro-"leaving behind" anyone.

    But that's exactly what you're doing.

    webchick’s picture

    I'm not sure it's useful to continue this conversation, since we've been going around in circles for awhile.

    I'm not part of the DA. I'm not pro-Slack. I'm an observer of community interactions, and reporting back what I'm observing.

    @hestenet is part of the DA, and has asked that we revisit this conversation once developer tools improvements (the current DA priority) is done.

    Seems reasonable to me.

    frob’s picture

    @webchick++

    Lets let this simmer until that done.

    NWOM’s picture

    After following along in this conversation for the past few months now, both sides of the equation make absolute sense in my opinion. I figured I'd maybe provide my own insight as well coming from perhaps a support oriented perspective.

    On one side of the coin, the community is already transitioning to a new system regardless of whether we are ready or not. So with this in mind, more options are potentially necessary right off the bat, whether it is a closed source or open source solution, especially since the community has already unofficially chosen a closed source solution.

    On the other side, we might be delaying the inevitable, and might just want to start off with an open source solution from the get-go which may be a bigger time investment, however it caters more towards the end-goal.

    -------

    However as it stands with Slack currently in-use, it adds its own limitations to the equation as well. None of the text is currently being indexed or archived, like it is currently on IRC.

    Also, I am of the opinion that with these more easily accessible solutions like Slack and Discord providing a more easy-to-use IRC equivalent form of communication; it is very likely that #support related queries will also increase on the "Slack/Discord" front; rather than via the current form of stack exchange tips, support issue threads, and IRC #support, which can all be searched via search engines.

    I propose that we first deal with the situation as it is now, and setup an indexer to at least the #support side of slack. We would have more flexibility to then choose either an open source or closed source solution and can migrate the text afterwards.

    dqd’s picture

    @ #365

    @webchick, That sounds a bit defeatist.

    No, its sounds concerned, caring and worried...

    ... Because of such things ...

    ... to participate in conversations that only happened in Slack

    ... proving that she is right.

    @webchick++

    As larger as a community gets as harder it will become to bring them all on one table to really make farsighted and smart decisions. Emotions and other gossip gets easier in the way than smart decisions are able to be made soon and can fastly become a snowslide. That's why I would love to see some more self-irony and smiles in all of our faces when looking in the mirror. And all community members being longer than a decade in Open Source communities know about these dangerous dynamics. So her worries are proven. We should really focus on Drupal and ask ourself how Drupal was able to become such a great project over such a long time and should put our own POV's a lil' bit on the side and should not overweight our own "things we believe to be right about". Ask yourself: If this would be such an important issue really, then, how has Drupal made it for so long without it? It's not meant future denying, but meant as a call for not letting it become a hot potato in all our hands.

    Errm, ok ... I maybe lost a lil' bit focus here as well ... it's maybe because I listen to Rachmaninov while typing this ... :p ...

    lightweight’s picture

    I've been doing Drupal for over a decade, and I've been watching other free and open source communities (Mozilla and Creative Commons) adopting Slack as a community messaging technology, and it saddens me deeply. I'm especially disappointed to see the leadership of those communities (and Drupal) advocating for using a fully closed technology to promote an open community. It's starting the slide towards fauxpen. This trend needs to stop. I've written a brief post explaining the problem: https://davelane.nz/arresting-slide-open-fauxpen I will abandon this community if the leadership does not recognise the need to be prefigurative - using means consistent with the aim of maintaining a thriving open community.

    Fine by me to support Slack as an alternative to a FOSS option, and all the FOSS ones have a "SlackBridge" functionality for those whose desktop is already afflicted with a Slackclient, but the first class solution needs to be FOSS.

    dqd’s picture

    diqidoq: As larger as a community gets as harder it will become to bring them all on one table to really make farsighted and smart decisions. Emotions and other gossip gets easier in the way than smart decisions are able to be made ...

    lightweight: I will abandon this community if the leadership does not recognise the need to be ...

    @lightweight, errm, that's exactly this kind of emotional sayings I Iwas talking about. Let's please calm down and let's have a relaxed and mature talk about a way out of this ..., well, quite secondary issue here... We should not fire such big words in situations where this is far too much for the actually issue. It's about a freaking chat protocol man, not about an unfixable core bug ...

    diqidoq: We should really focus on Drupal and ask ourself how Drupal was able to become such a great project over such a long time and should put our own POV's a lil' bit on the side and should not overweight our own "things we believe to be right about"...

    wizonesolutions’s picture

    Zulip's Twitter account told me that they offer fully-functional accounts for open source projects: https://twitter.com/zulip/status/909177760106536961

    We last looked at Zulip a couple years ago. Perhaps the experience has gotten better since that time, and it warrants another look? I haven't looked at it myself. A half-joke tweet about Slack, the message limit, and my verbose rubber ducking just turned into an unexpected conversation about this thread :) (hi @lightweight)

    lightweight’s picture

    Given that most hosted solutions use a per-seat cost model, e.g. Slack's, for a huge and growing community like Drupal, it makes sense to host your own open source messaging option (or pay someone a fixed amount to do it) so that your scaling cost is far more tractable, and grows with infrastructure requirements (which will surely be a far more favourable cost/participant ratio), not based on some arbitrary per-user model. A per-user model is a significant cost risk if the community continues growing. (howdy @wizeonesolutions :) )

    Update: ah, I see that some enterprising Drupalers in the EU have already set up a Rocket.Chat - joined that already. Sounds like it'll scale to meet the community's needs, without the price tag. I'd be very surprised if a community as valuable as Drupal didn't get sponsored hosting capacity thrown at it by enthusiastic providers.

    freelock’s picture

    New blog post from Matrix.org, where they have addressed some phishing and spam concerns of some other open source crypto-currency communities: https://matrix.org/blog/2017/09/19/matrix-riot-for-cryptocurrency-commun... ... this allows people to set up a Matrix server that can block non-trusted DM invitations for its users...

    Alex Malkov’s picture

    Some history of slack-chat became paid. See the screenshot https://seafile.93323.ru/thumbnail/3ed17aab66934fbfa477/1024/2017-09-20-...

    kevinquillen’s picture

    Yes, it is a rolling 10k message history limit. We hit this limit fairly fast last year with 120 people (across ~70 chat rooms in our org). Now we pay for Slack, and it costs us about $12k a year, which I find expensive for a fairly low amount of people. Having been through the ringer with a lot of chat platforms (yet to try Riot/Matrix), free Slack doesn't really solve anything except lower the barrier of entry to get into the app, and then there are paywalls everywhere.

    ekes’s picture

    I'm guessing this is the issue that got riot.im client partly banned from #drupal-* channels on Freenode so I'll note this here:

    At Drupalcon I've now had to help several people who use riot as their IRC client. I'm not sure they are even aware of the differences about Matrix and Freenode, and certainly don't know about the ins-and-outs of this discussion.

    It is deeply unfriendly for first time sprinters to get a 'Banned' notice when they try and join the IRC channel, it's also quite confusing. Explaining registering a nick, or changing to remove the [m] doesn't really help. I had a new contributor who had ended up installing another IRC client, on top of riot that they normally use, just to get into IRC because they didn't understand.

    ricardoamaro’s picture

    You are right @ekes and i think any filtering right now doesn't make any sense anymore after our BoF session.

    I'm asking to please remove the filtering from drupal-* channels. There are have been also cases of Drupal local communities wanting to use their own channel the way they want like Drupal-pt, Drupal-in and few others. They have that right. So let's remove the filters. This enforcing of security is going way above what a chat platform needs to work well and is making hard for people to contribute to the community, as @ekes said.

    In the BoF in Vienna there was a strategy defined. I've updated: https://www.drupal.org/node/2905534 with meeting notes and next steps

    lpalgarvio’s picture

    Letting everyone know of the discussions on the Community Summit and the BOF session at the DrupalCon Vienna, followed by some progress.

    This was heavily debated and consensus was achieved with the people present (about 14 people).
    Consult the document here - https://etherpad.openstack.org/p/drupal-chat-bof
    Additional info - https://drive.google.com/drive/folders/0B-39hK-7nJXKTHpLbkRnd1lKR2s

    We are currently working on PoC of Matrix and Rocket.Chat servers, supported by community members (floris, lpalgarvio, betz and ekes).
    Bridges may be addressed in the near future, as well as SSO authentication against drupal.org.
    All these are experimental and controlled, and will be reviewed periodically.

    The objective is to research and then reach conclusions before eventually a decision is made. Any decision that implies costs will probably have sponsors behind, and there is already parties interested.

    Problems:

    It is evident there are problems to address with the current "official" implementation in IRC. Citing a few:

    • Impersonation is possible, because no SSO implementation is in place to authenticate against drupal.org.
    • No permanent storage and sync of messages on the server.
    • No GDPR policy support.
    • Outdated protocol with it's own issues.
    • No support or no proper support for modern features (VoIP, Video call, file transfer and sharing, resume connection).
    • Clients still feel dated.
    • Bridges are banned / not allowed on the "official" drupal channels.

    The same is valid for the "unofficial" implementation of Slack. Citing a few:

    • Impersonation is possible, because no SSO implementation is in place to authenticate against drupal.org.
    • No permanent storage of messages, and limited to 10k on free service.
    • No GDPR policy support.
    • No administrators per channel makes managing communities and giving autonomy impossible.
    • Bridges are banned / not allowed on the main slack team.
    • Community is fragmenting into multiple silos (different slack teams) because of the issues above.

    Solutions:

    • Matrix server - PoC planned and in progress. Stability: dev.
    • Rocket.Chat server - PoC planned and in progress. Stability: beta.
    • Federate - Federation allows for increasing availability and collaboration - PoC planned and in progress. No (in)Stability implied.
    • Bridges between both servers - PoC planned, todo.
    • Bridges from either to IRC, Slack, and other options - To be research and defined.
    • SSO - To be researched and defined.

    Concerns:

    • Impersonation - Not valid at the moment, because this already happens on IRC and Slack. This is limited and can be avoided completely on Matrix and Rocket.Chat under certain server configurations. Our goal is to prevent this from happening by using SSO authentication against drupal.org and providing efficient ways of validating users identities. In any context as the current situation is presented, Matrix and Rocket.Chat will always be safer.
    • Privacy - Public channels are opt-in bridged, and not opt-out. Private channels are not bridged.
    • Trust - There is a team assembled for running these servers and it has members from the Drupal Association, Drupal.org Infra team and Drupal IRC team.
    • Effort - The same team will setup and maintain everything during PoC and afterwards, if a decision is made on that direction.
    • Costs - Sponsors will provide funding if sponsoring is required.

    You may try these servers here:

    Rocket.Chat - https://drupalchat.eu/
    Matrix - https://drupalch.at/

    hestenet’s picture

    Status: Postponed » Closed (works as designed)

    I wanted to post a follow up here after several excellent discussions that have taken place: in person at DrupalCon sprints and in the chat BoF(thank you for posting notes @lpalgarvio), online, and by video conference with the current IRC admins.

    The Birds of a Feather session at DrupalCon Vienna was a good reminder that the hardest problems to solve are the human ones, not the technical ones, and these are the problems that most require empathy and collaboration in the spirit of open source.

    The fundamental problem that people on all sides of this issue want to solve is this:

    • Changes in the landscape of online chat options are fragmenting the community and community conversation.

    People have a variety of preferences in communication mechanisms, with diverse motivations rooted in free software advocacy, privacy and security concerns, or the powerful convenience of using tools that are already central to their daily workflow.

    If necessary, a decentralized communication channels are okay - but forking communication, and thus our community, is not.

    One of the only ways to achieve decentralized communication without forking is through a bridging solution- as was initially proposed here, but several members of the community raised serious concerns having to do with identity/impersonation, notification of bridging, moderating across multiple platforms, and more.

    Fortunately, following DrupalCon and several other conversations I believe we've created a roadmap that should help resolve these issues:

    Identity/Impersonation protection

    • Minimum: Bridged protocols should check for a registered nick via services, and prompt users to authenticate and/or register the new nick.
    • Preferred: Bridged protocols should use a central authentication authority such as an Oauth endpoint of Drupal.org (which does not yet exist). As well as checking for the nick being registered before the bridged connection is created.

    Notification

    • Bridged rooms should notify users of what other protocols the channel is bridged to (notification must appear to users on all sides of the bridge)
    • Bridged rooms should notify users that some bridged protocols won't support edited or deleted comments.
    • Kick/ban notices need to propagate properly across bridges.
    • Ghosting and presence indicators must propagate properly across bridges.

    Moderation

    • The team of moderators should be equal across bridged platforms, with equal privileges on all sides of a bridge.
    • Moderators for any protocols involved in the bridge must apply in the issue queue and be approved by the current team of moderators.
    • The bridge needs to allow moderators to disable or enable the bridge from either side.

    Configuration management

    • The proper setup and configuration of a) a matrix server b) channel bridging c) etc need to be well documented so they can be understood by the DA infrastructure team.
    • A puppet manifest for managing that server should be generated.

    Most of these issues are technical ones that can be resolved with the help of users in our community who are experienced with Matrix as a tool and can create patches to fix the underlying issues, or perhaps with the help of the Matrix team. Some of these issues are matters of policy.

    For all of these, we should document our direction as we go in the issue queues, as well as the use cases that motivate each element.

    Because this issue has become so unwieldy, I propose that we close this current issue, and open a new one in a dedicated issue queue, with the steps outlined above in the issue summary as our roadmap to advance the use of Matrix for bridging IRC. The infra team may also review other chat platforms that are in use by various regional communities and create a list like the one above for evaluating/integrating those as well.

    Here is the project we've created for resolving the issues above, and hopefully move forward with Matrix bridging: https://www.drupal.org/project/matrixchat

    I've created a meta issue in that project for resolving the Matrix-specific issues: #2916635: [meta] Issues to be resolved to enable Matrix bridging with IRC

    ricardoamaro’s picture

    Thanks @hestenet
    I thinks this is great feedback. I personally agree on all the points and let's move forward with Matrix bridging: https://www.drupal.org/project/matrixchat

    dqd’s picture

    Valuably and extensively written summaries and info sheets, @lpalgarvio @hestenet. Thanks for the hard work on this and all the empathic concerns and conversations you followed, merged and reported back in a forward thinking and postive/constructive manner. Sadly not all of who have concerns were able to join your offline discussions, but your representation seems sensitive and well done.

    One thing I would like to add to the well formed and forward thinking concern here: "If necessary, a decentralized communication channels are okay - but forking communication, and thus our community, is not." is that the first Okay is caused by the reality of "Changes in the landscape of online chat options are fragmenting the community and community conversation." and therefore it is inevitably required to nitpick on a still existing and resilient low level entry for all community members via IRC being able to communicate with all others (the bridged ones) without additional tools required the same way it used to be. I know it's implemented in your "round-ups" actually, but I felt the need to highlight it one more time.

    TL;DR: "new features should not break old features", IRC is still THE chat solution for many Open Source communities and should keep being the "bottom" from where we add new on top.

    P.S. Is "(Works as designed)" the right status?

    colan’s picture

    Status: Closed (works as designed) » Closed (outdated)
    Related issues: +#2906243: Allow matrix users to use matrix as an IRC bouncer client

    I believe this is the better status.

    #380: The issue for that is #2906243: Allow matrix users to use matrix as an IRC bouncer client.

    frob’s picture

    Honestly I think "fixed" is the correct status, but "outdated" works too. The goal of this issue was to "Evaluate whether to replace drupal IRC" and I think we did that and now we have a plan to modernize. Way to go everyone! :)

    colan’s picture

    Status: Closed (outdated) » Fixed

    Here you go!

    fuzzy76’s picture

    While these are great principles, I fear you are effectively raising the bar for bridging so high that no bridge will satisfy the requirements without a lot of development (which I predict won't happen). These changes require a node.js developer that somehow want to do a lot of work to satisfy a PHP community.

    dqd’s picture

    you are effectively raising the bar for bridging so high that no bridge will satisfy the requirements

    @fuzzy76: Who is "you"? Can you refer to a post you answer to? Here are many thoughts in it. And your solution? Or are you advocating for lowering the "principles"? Which would - if you mean what I think you mean - turn many away from new chat implementations. Including me. Like many, I am involved in many different Open Source development communities and I am absolutely fine with IRC but accept new implementations and contributing to them, if the community wants it. But I won't follow on the edge.

    fuzzy76’s picture

    @diqidoq By "you" I am referring to the consensus expressed by @hestenet in #383. I think the requirements set require us to write our own chat bridges (or atleast contribute heavily to an exising one), which I doubt will happen. Drupal has this tendency of amassing requirements through bikeshedding which ends up preventing adoption of practices from elsewhere.

    Status: Fixed » Closed (fixed)

    Automatically closed - issue fixed for 2 weeks with no activity.

    matthieuscarset’s picture

    There are only 53 responses to Surveymonkey... not really sure those results represent our community ! :|

    dasjo’s picture

    Sorry I don't fully understand what the decision was at the end of this issue. Could someone point me to the next steps? Thanks!

    I just came across this again, because at a DrupalCamp in Germany, the local communities decided they want to go away from Slack and move to DrupalChat.eu as the central place for chat communication.

    andypost’s picture

    @dasjo I think it makes sense to create follow-up about https://drupalchat.eu/home and it's rules, registration and probably integration with Matrix https://github.com/matrix-org/matrix-appservice-rocketchat

    IMO RocketChat is very nice tool! I using it more then year without issues

    dasjo’s picture

    Thanks for that andypost. I have created a brief follow up #2954073: Promote Rocket Chat instance as an alternative to Slack