Please don't use Slack for FOSS projects - <AUTHOR> https://drewdevault.com/2015/11/01/Please-stop-using-slack.html <comment><USER2> If IRC were good enough to handle the needs of small software company communication, _people would use IRC_. Sitting here pretending everyone just doesn't know about a 20+ year old technology is comical.

The "IRC Features" section bugs me, too. Unless you run a private IRC server IRC has a long, tortured history of design-based security difficulties. Gone are the days of netsplits permanently owning channels, but the so called "distributed" design of IRC makes it very brittle and easy to deny service.

Oh, and did you know that with modest, low volume channels (>200 <1000, some networks tolerate more) you can make IRC networks struggle? Turns out that their lousy distributed design hurts more than helps when single channels get heavy.

Slack also offers a logging service that, for what it's worth, is configured correctly and secured by default. For organizations with 1-3 technical staff, maintaining and securing a reasonable approximation of Slack's feature is probably time better spent working on your product.

IRC is a classic example of the "it's broke but we don't fix it because it's familiar" mentality of old school services. While it may be a good choice for running low-volume (<500 users) public communication. Most tooling around it is woefully inadequate and often tedious to use for small software-oriented teams where Slack thrives.

But if you're genuinely concerned about security, HipChat will sell you a whitelabel product you can host and monitor and its setup is quite good for what it is.

<comment><USER3> > If IRC were good enough to handle the needs of small software company > communication, people would use IRC. Sitting here pretending everyone just > doesn't know about a 20+ year old technology is comical.

I'd just like to point out that this argument ("if <x> were so great, everyone would already use/do <x>") is just a slightly different form of the ancient appeal to popularity argument and is entirely fallacious.

<comment><USER4> Respectfully, I disagree. In many cases, things are popular because they are better/easier for a given audience. I'm a smart guy, have managed (and continue to manage) many, many UNIX-based services, and have run several IRC daemons in my life.

I still use Slack for internal use, and for our students.

What makes Slack (and its ilk, though the title of the post makes a bias against Slack clear) so great is that it's simple, easy, full-featured and has a low barrier to entry to the non-HN crowd that is being asked, in many cases, to use it.

I can promise you, out of experience and out of just plain statistics, that Slack and IRC have different audiences, and those audiences will not likely prefer the other.

Also, I'd guess that IRC is actually the more popular choice. But the majority of the IRC using audience is too busy getting work done in IRC to comment on an HN post.

<comment><USER5> I don't think you're going to find evidence for the argument that IRC is more popular than Slack. IRC's user base is declining, Slack's is growing, and the numbers we have now suggest that Slack is already much more popular.

<comment><USER6> Slack has 1.1 million users _total_ ([http://www.fastcompany.com/3047819/with- over-1-million-users...](http://www.fastcompany.com/3047819/with- over-1-million-users-slack-now-aims-to-get-a-lot-more-useful)), meanwhile Twitch uses IRC, and has ~3.3 million per day alone ([http://blogs.wsj.com/digits/2015/01/29/twitchs-viewers- reach...](http://blogs.wsj.com/digits/2015/01/29/twitchs-viewers- reach-100-million-a-month)), using stats taken eleven months ago while more than doubling its monthly viewer numbers every year.

Freenode isn't the only network out there =)

<comment><USER7> I think that's the problem with IRC. The idea of decentralized IRC networks means that channels are scattered amongst multiple IRC networks. IRC is already not as usable as Slack, and to have multiple networks decreases usability even further. I love IRC, but I see why Slack is full of win.

<comment><USER8> But decentralized is the best thing ever!

I hate that argument. If decentralized was so great, then it'd be more popular, but it's not. More and more centralized stuff is exploding in popularity.

<comment><USER9> Centralization is being driven by a lot of things, not least of which is that decentralization is really really hard. But a lot of it comes from mobile -- the idea behind decentralized apps before mobile came along was that bandwidth was not very dear -- oh, sure, it was limited in the days when IRC first became popular, but there was no reason to leave any of it unused. Local compute power was the same -- you may not have had a lot of it, but there was no reason to leave what you had sitting idle. Mobile is different. Idle CPU power can mean the CPU is throttled down to save on power and heat dissipation. Instead of staying connected to a server at all times, use "push" notifications so the server can let you know when it's worth using battery power and metered data to talk to the server.

Decentralized systems, and peer-to-peer systems, and even centralized systems designed around computers designed to sit next to a wall outlet and draw power from a practically unlimited source are all being replaced by systems that are more centralized and better equipped to talk to mobile. AOL Instant Messenger is dying because it was built around an older paradigm and, at least last time I bothered to try it, is an incredible battery drain on Android devices. Newer messenger apps that are built mobile first or at least make mobile an equal partner to PCs are winning instead. And it's the same for group chat -- IRC is built for old-fashioned PCs, Slack is built with mobile in mind.

<comment><USER2> It's also worth noting that it's not clear what decentralization brings to the table from the perspective any single organization. Most organizations will want a central authority for the history of their group communications.

Such facilities are bolted onto IRC, but never truly integrate with it the way other solutions have offered.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Allow me to shout into the void for a minute here...

1\. Slack is a well-designed interface for allowing teams to communicate via chat.

2\. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just Works™.

3\. Slack doesn't require me to install IRC somewhere. Which also means I don't have to worry about how people gain connectivity to said server when outside the office.

4\. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.

All of this is what folks in this thread seem to be missing. I've used IRC for a very long time, but have NEVER been successful at getting wide adoption of IRC for communication.

I am well aware that I'm trusting a third party with out information. I'm aware that alternatives exist and you can get them to work. That doesn't matter when I have to try to explain to my CEO how to /join #channel.

There is a reason why IRC, a widely-available, chat solution that has been available for decades didn't catch on. It has nothing to do with how well the software moves messages from one computer to another.

</rant>

<comment><USER11> > 1\. Slack is a well-designed interface for allowing teams to communicate via > chat.

subjective. I consider a bloated web interface taking several tens to hundreds of megabytes of RAM compared to a text-based interface taking less than 100 kB to be poorly designed.

> 2\. Slack is easy to install is use on Mac, PC, iOS, and Android. It Just > Works™.

spelled wrong, and IRC clients are harder to configure only because there are so many options for servers, whereas Slack only supports one server.

> 3\. Slack doesn't require me to install IRC somewhere. Which also means I > don't have to worry about how people gain connectivity to said server when > outside the office.

webchat was invented for a reason

> 4\. Slack has whimsy. Fun colors, messaging, emoticon, bots, etc.

IRC has had mIRC-style colors supported and even adjustable by the majority of clients for at least 10 years. I don't know what "messaging" means. If you mean "private messaging", pretty much every chat software in the world has that. AOL and ICQ have that. You can put emoticons in your text manually if you want. It was on IRC that the concept of chat bots was _invented_ , not on Slack.

> There is a reason why IRC, a widely-available, chat solution that has been > available for decades didn't catch on. It has nothing to do with how well > the software moves messages from one computer to another.

Yes, it is about how much money a for-profit company has to spend on marketing and copy as opposed to a standards organization.

<comment><USER12> This whole response reads like it was written in the 90's. Most people don't care if something takes up 10's of MB's of RAM when new PC's are shipping with 16-32GB standard.

Your comparison of what amounts to ASCII art versus Slack's rich-media embedding reads like it is straight out of a Fortran developer's "I'm still relevant" handbook. You even offer up AOL and ICQ as counter examples!

If we're going there, I guess we should simply assign everyone a GUID and be done with it, right?

HMU on ICQ: 110339943

<comment><USER13> > Most people don't care if something takes up 10's of MB's of RAM when new > PC's are shipping with 16-32GB standard.

ISTR a -now undoubtedly outdated- answer to a question that was very much like "Why will there not be a _real_ Photoshop clone for mobile devices in the near future?". One of the striking things to come out of the analysis was that -absolute best case- you got something like ~300MB of RAM (and -common case- ~100MB) to work with before you got _unceremoniously_ killed.

I would _hope_ that now you can _reliably_ consume ~500MB of RAM per app, but... that's still a _far_ cry from what you can use on a "real" PC.

Unfortunately, memory usage still matters. :(

</comment></comment></comment></comment><comment><USER14> Please for the love of god just don't use Slack.

We have learned absolutely nothing. Let's all jump on the bandwagon of another closed-source, proprietary, walled-garden service and hand over all of our private intra-company communications to a private third-party in another country. GREAT IDEA.

<comment><USER15> Agreed, _but with that said_... IRC has serious issues, and dancing around them or pretending they're not there is not helping. I talk a bit about them here:

[https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...](https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToBsQ)

The reason Slack exists and can be so successful yet entirely proprietary is a symptom that IRC is _not good enough_ and that has to be fixed. It is the manifestation of the papercuts we, IRC users, have been having for a long time now. (late edit: If you are interested in fixing this problem, email me, see my profile.)

There are very promising efforts on IRCv3 ([http://ircv3.net/](http://ircv3.net/)) ongoing. I hope they eventually go live to the bigger clients and networks so that we may actually have a good foss alternative to slack (and I don't mean something like Mattermost. Like SirCmpwn said some comments below, having one browser tab per project REALLY SUCKS when you contribute to a lot of projects. I'm in over 20 channels myself, and I do my best to keep that number low...).

<comment><USER16> I really resonate with this position. IRC is open source and it has had problems FOR DECADES. IM programs from third parties add genuinely useful features which people clearly want. So rather than call for a general boycott of Slack (a negative approach) why not call to fix IRC?

<comment><USER17> IRC is just a well-established and battle-tested server/client protocol. I'm eager for the day when a competing open source server/client protocol emerges and takes over. I imagine all it would take is a really good reference implementation server and client that everyone can just start using, right?

<comment><USER16> I certainly think having an open source reference implementation for a 21st century (and by that I mean having features like Slack or Yammer or other popular closed source packages) implementation of a successor to IRC would be the minimum starting point.

<comment><USER18> From what I've been able to gather, the open project that is most like Slack, but also offers self-host, decentralization is Matrix:

      http://www.matrix.org/

There's also Zulip, which as far as I can gather, is battle-tested, but does not have a strong story for federated servers, nor a good out-of-box experience for really small servers:

      https://github.com/zulip/zulip

Finnaly there's [https://tox.chat](https://tox.chat) \-- which doesn't have a lot of the things IRC/Slack has (it's focused around p2p chat) -- but extensions are planned, for eg. persistent group chat. Perhaps most excitingly "new" of the three, which predictably is both a good and a bad thing:

      https://wiki.tox.chat/users/faq#what_is_tox

For those that "want Slack", but self-hosted, open/free software server -- I think Matrix is the most viable alternative -- if IRC is seen as not good enough.

I've not included any XMPP servers, although eg. Prosody should be simple to set up and use -- because, apparently like IRC, it has too many problems for people to actually embrace out-of-the box XMPP for team chat. The fact that most big public services that host XMPP tend to favour anonymity probably has something to do with the fact that getting reliable server-side message logging and off-line messaging is still not as easy as one would expect, for any(?) of the big free XMMP daemons (or indeed support client side).

[ed: Matrix also have some support through bots/plugins for IRC bridging: [https://github.com/matrix-org/matrix-appservice- irc](https://github.com/matrix-org/matrix-appservice-irc) ]

<comment><USER19> Actually, bridging is actually a first class citizen in Matrix - it's why the project's called Matrix (as we want to go federate/matrix together all the existing silos out there). Current bridges include:

* IRC ([https://github.com/matrix-org/matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc))

* Slack ([https://github.com/matrix-org/matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack))

* Verto ([https://github.com/matrix-org/matrix-appservice-verto](https://github.com/matrix-org/matrix-appservice-verto)) (for talking VoIP with FreeSWITCHes)

* Respoke ([https://github.com/matrix-org/matrix-appservice-respoke](https://github.com/matrix-org/matrix-appservice-respoke)) (for talking VoIP with Asterisks)

* Purple ([https://github.com/matrix-org/node-purple/tree/master/appser...](https://github.com/matrix-org/node-purple/tree/master/appservice)) (for talking through to Skype, Facebook, XMPP, ICQ, AIM... and anything else that libpurple supports)

...and a whole bunch of 3rd party ones too like [https://github.com/SkaveRat/xmpptrix](https://github.com/SkaveRat/xmpptrix). Some of these are pretty beta, but they're all headed in the right direction. The IRC and Slack ones are the most mature.

Glad to hear that you think we are on the right track! [Disclaimer; i work on Matrix]

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> Some open source self-hosted alternatives to Slack:

* Rocket.Chat ([https://rocket.chat/](https://rocket.chat/))

* Zulip ([https://zulip.org/](https://zulip.org/))

* Mattermost ([http://www.mattermost.org/](http://www.mattermost.org/))

* Let's Chat ([http://sdelements.github.io/lets-chat/](http://sdelements.github.io/lets-chat/))

Oh, and by the way, you could have your own Rocket.Chat instance running in Sandstorm in about 30 seconds: [https://sandstorm.io/apps](https://sandstorm.io/apps)

 _Update._ And I would love to see a modern federated chat protocol to take off. Something like [http://matrix.org/](http://matrix.org/).

<comment><USER21> Not sure why I would want to self host what is effectively a phone system. I have actual products to build. We could ease time self hosting source control as well -- to what end? I have members of the team spending time (and thus money) setting up something that pleases people philosophically but really adds zero value -- in fact, it actually costs money (through very expensive developer time.)

I don't get the point of complaining about Slack. It works great, it's simple to use and it has an amazing feature set. IRC is pretty terrible. Try doing a drag and drop file transfer. Try using markdown. Try displaying images inline.

I don't get what the problem is with closed source Slack. Do we avoid the phone company because their software is closed source? There comes a point where this FOSS obsession sort of jumps the shark. Worrying about a 'walled garden' for a chat tool is kind of silly. If it bothers people so much, create a FOSS Slack with the ease of use and setup and maybe people would be more interested. But anything that requires me to 'self host' something that amounts to a service means that is a bad use of time. I can pay the Slack guys to maintain chat while my devs work on maintaining our products. IRC is terrible. Try and get someone from your marketing department to use IRC. The neck beard and almost hipster pontification about the 'bloat' of Slack is kind of ridiculous. We have better things to worry about. Slack works on all my devices perfectly. I have a searchable log of everything. I don't have to think or worry about anything. It's simple and works. Until there's a viable alternative that exceeds Slack's ease of use, that's what I recommend people use.

<comment><USER20> > IRC is terrible.

I didn't mention IRC in my comment :)

It's interesting how you compare Slack with a phone company. There are important differences between Slack and a phone company. 1. If you give me your phone number I could be talking with you in a few seconds without me even knowing the name of our phone company. 2. You could decide to change your phone service provider and (in some countries) even keep your number.

How would you do these things with Slack? Slack is great, and I like it, but it could stop being great at some point in the future.

(Yes, I realize that Rocket.Chat user couldn't chat with Zulip user, for example. That's why I'm excited about efforts like [https://matrix.org/.](https://matrix.org/.))

I agree with you: it's expensive to self-host. [1] But when it is _possible_ to self-host, you could hire a specialized company to host the chat system for you. And - if you are careful - you can later switch your chat-system-hosting provider if you want.

[1]: That's what [https://sandstorm.io](https://sandstorm.io) is trying to fix, by the way.

</comment></comment></comment><comment><USER22> It is reasonable to raise the point that building FOSS software while using a closed piece of software as a core tool bears consideration.

However, I am 25 and largely missed the boat on irc. I decided to start using it ~1 year ago. It is hard to use, but we will look at that in a minute. Often, we assume people have as clear an idea of what we are talking about as we do. That is often _not_ the case. Let's explore IRC now.

* Integration has never been a problem ... build bots.

I feel silly and naive, should I know how to set this up? Maybe it is really easy and well documented, and I am an edge case here, but i don't know how to do this. I clicked 3 buttons to setup github for slack. It was very easy and I didn't haystack through building a solution to something that exists. Scope creep on tooling is dangerous as an aside. Thos takes that off the table.

* persistence

again, I have to set up an alternate tool to download the content. i assume this would backup the whole channel so any user could reference it, but it comes by default for free with slack. if each user must have a seperate tool, or go to a seperate place to see a conversation (which may be less searchable) it adds friction.

* code snippets

actually super reasonable to use pastebin. slack is at least as annoying for code as pastebin, if not more.

* etc

The point is, not everyone lnows as much as the author about IRC who is likely quite a talented developer who grew up on it. An 18 year old likely won't have used irc as much as older generations given the plethora of tools and chat clients.

FOSS is a choice and a philosophy and that should be given some degree of consideration. Utility, workflow and getting new devs onboard and contributing is important. I agree with the author that it bears consideration, but slack or hipchat are _much_ easier than IRC.

<comment><USER23> It's worth mentioning that Zulip ([https://zulip.org/](https://zulip.org/)) is a new open source option that has basically all the features IRC/Slack does. So using open source tools for open source development doesn't have to mean dealing with IRC's limitations.

(I'm one of the Zulip maintainers; happy to answer any questions about it).

<comment><USER24> I've been meaning to give Zulip a try. How many users can it handle?

Less importantly: What would you say its biggest missing feature is vs Slack? And conversely what does it bring to the table that Slack can't touch yet?

<comment><USER25> I'll field the latter. I've used both Zulip and Slack in small team (5-20 people) settings and I much prefer Zulip.

In particular I like how the zulip UI is single-stream by default. Messages from different channels are interleaved, so you can read all new messages at a glance, but still well separated by visual elements including color - I don't find it confusing. And I can focus down to any particular channel , or reply to that channel, in one click.

It goes all-in on this "many streams, one view" model with the concept of topics - lightweight "subject headers" for individual sub-streams of a channel. This neatly avoids the "two conversations at once" problems that can occur in other systems occasionally.

Some more minor points are a wider range of markup available than slack (including syntax highlighting for code), and better support for short-lived private groups (ie. "a PM between Alice, Bob and Charlie")

As to what I think Slack does better: More one-click integrations (and likely other backend admin stuff that I don't see as a simple user). AFAIK Zulip doesn't have an irc gateway. Also when I last used it (over a year ago) Zulip's mobile client was quite poor.

I'm sure others can come up with more differences - to be honest I tend to treat slack as "slightly smarter irc" so I don't pay attention to all the bells and whistles.

Finally I should caveat that these same features I like are things people dislike about Zulip - it's more dissimilar to existing solutions and people will always have their preferred ways of doing things. I personally find Zulip amazing for me.

<comment><USER23> FWIW Zulip does have a beta-quality IRC gateway (bots/irc-mirror.py); anyone interested in working on improving that should check out this issue: [https://github.com/zulip/zulip/issues/249](https://github.com/zulip/zulip/issues/249)

</comment></comment></comment></comment></comment><comment><USER26> The author makes a huge list of all the things Slack does and then goes on to suggest time-consuming ways to hack standard IRC clients to do the same thing. The question is: why in this day and age should we have to do that?

Have you ever noticed just how many open source projects are still using shitty software from the 90s? No doubt, some of that software is actually quite good but I will argue most of it exists primarily as a result of tradition. In other words: a lot of it isn't the best way to do things presently, and perhaps if we stopped using such mediums as: mailing lists, newsgroups, and IRC channels to run our open source projects then presumably our projects might be filled with more diverse people than dinosaurs that still roam our mailing lists.

I don't know why developers do this: but they assume because they have the skill to do just about anything with technology that other people who also have the skill ought to take the same time to do as they have. But honestly: even developer time is too valuable to waste on pointless shit. We ought to be trying to make things easier to use.

</comment><comment><USER5> If you don't want to use Slack for open source projects because it's closed- source, fine. That's a reasonable argument.

If you don't want to use Slack for open source projects because Slack is in fact pretty bad at those workloads, fine. I agree! I think Slack does a pretty bad job at any group application where most of the people communicating don't already know each other.

Where you go off the rails is in suggesting that IRC is competitive with Slack. IRC is awful. It's a medium dominated by 7-bit clients with tiny message limits that provides virtually no useful metadata and no works-by- default history or search --- both things that virtually every open source IRC support channel _b a d l y_ needs.

IRC does exactly one thing better than Slack: it's easier to join a new IRC channel than it is to join a new Slack project. The rest of IRC's "features" are red herrings, many of them more harmful than helpful.

Surely by now someone has built a Slack-like, perhaps with decent IRC support, that big open source projects can champion as a Slack- and IRC alternative.

It will be much easier to keep open source projects from trying to fit their square pegs into Slack's round aperture when people give up on promoting IRC.

<comment><USER27> "Awful" technologies can still be fulfilling.

I mean... Hacker News is pretty "awful."

Maybe the things that you claim make IRC "awful" actually have weird benefits in terms of community. Kind of like how HN is kept intentionally awful, to keep out the losers or whatever.

<comment><USER5> Yes, I think the comparison to HN is especially apt.

</comment></comment></comment><comment><USER28> This is the perfect counter example to "Open source is better". IRC has been around for 20+ years. But a company that is just a few years old blows it away feature-wise. Sure, you _can_ do all the same stuff in IRC, but look right at the article for why you wouldn't. The answer to every "missing feature" in IRC is to install some extra software and then maintain it.

I'm don't want to waste time doing that, I've got products to build and maintain.

The closed source option is better because they have a financial incentive to keep it that way. And I'm happy to pay for that because it saves me time and lets me work on things for my customers instead of myself.

I'm a huge fan of open source and used to be a zealot about using open source to run my business. But I've started to see the light in my old age.

<comment><USER29> I generally agree, though I'm not sure financial incentive is the reason. Open source has really shown that financial incentive is (A) complex and (B) not the only thing that motivates people.

If you look at open and closed source across a lot of categories, I think it's more common to see OS "win" where the product is more objective. When it come to more subjective problems like UX, it seems to be more difficult.

If your goal is something fairly objective OS is really amazing. Take VLC's "play everything everywhere" goal. Fantastic, objective goal for and OS project that really plays to its strengths.

Linux is, I guess, the canonical example. It's fantastically successful relative to closed source competitors on every front that is objective. But, its consistently been unsuccessful as a consumer desktop.

That said, I don't think IRC is dead either. Some people/communities prefer IRC.

<comment><USER30> What you're trying to say is that open source works best when there's little or no design work involved and little or no product vision required.

Linux is a canonical example: it's simply a clone, design wise, of a plain old UNIX. The product vision was "copy UNIX". Where the wheels fell off Linux is the moment it got ahead of the UNIX legacy (i.e. modern desktops) and started having to compete with Windows, so suddenly the "copy UNIX" goal was no longer relevant. But Windows was made by Microsoft, or "the great satan" as Stallman memory called it.

So simply switching the goal to "copy Windows" wasn't possible because Windows and UNIX were very different and anyway, lots of people hated Windows. Linux had picked up a lot of semi-technical and technical users who didn't care much about FOSS purity but loved the club feeling that using an obscure OS brought them. The end result was big splits and bizarre, illogical design decisions being made simply because "do it like Windows did" was ideologically unthinkable, even when Windows had basically got it right (or at least, less wrong).

</comment></comment></comment><comment><USER19> [Slightly naughty crosspost from [https://drewdevault.com/2015/11/01/Please- stop-using-slack.h...](https://drewdevault.com/2015/11/01/Please-stop-using- slack.html#comment-2337758257)]

There are an increasing number of plausible FOSS alternatives to Slack out there like Zulip, Mattermost, LetsChat, RocketChat etc. Classic IRC simply doesn't compete in terms of the featureset, glossy clients and web-dev friendliness. However, most of the FOSS Slack clones miss one vital point: they just provide a random custom API to their clients which may not even be published. Despite being FOSS software they're not actually promoting Open Communication - they are just building yet more silos that fragment your conversation history and contacts/contactability even further. If you want to pick your own client, or pick your own server, or interoperate with other comms networks (other than naive bridging), you're generally out of luck.

This is why I personally believe it's vital to support open standards for communication like Matrix.org or XMPP or IRCv3, and build glossy clients and services on top, so that rather than being locked into a single server & client from any given project, we retain the freedom to pick the clients, servers, services and service providers that _we_ want rather than being forced into using particular ones for particular communities. A good start would be for the Zulips and Mattermosts of this world to federate with Matrix or XMPP out of the box, even at the lowest-common-denominator functionality set, to support open communication rather than causing yet more fragmentation.

[Disclaimer: I work on Matrix.org]

</comment><comment><USER31> Somewhat tangential but relevant, what the hell happened to XMPP, period? Wasn't it supposed to be our one communication account we do groupchat, video calls, IMs with persistence, and file transfers over? Why did it just up and die with nobody working on it and nobody using it?

[http://xmpp.org/extensions/xep-0045.html](http://xmpp.org/extensions/xep-0045.html) exists. Its groupchat, it could probably be amended to support inline code, and its persistence model lets a server chose to broadcast the message history or not.

And it is incredibly more user-friendly to make an XMPP account through a GUI client, have username@server, then join group@server for groupchat. No /join, no /register, no port management or #channel management. Hell, any reasonable XMPP client would default to your current server for groupchat so when you click "join chat room" you get the server part prefilled and you just enter the group name (or pick it from a list of groups - the protocol supports channel announcements).

I get that XMPP is a horrible format (XML) and horribly bloated (committee) and horribly old (1999?) but if its that broken why can't we make another protocol for peer to peer realtime communications? Why isn't webrtc becoming that transport? Why do we keep getting these one shot web startups trying to replace open protocols every other weekend for a quick buck?

<comment><USER15> Previous discussion on this: [https://news.ycombinator.com/item?id=10280611](https://news.ycombinator.com/item?id=10280611)

It's sad. But the only thing that can be done is work on an actual protocol that _will_ solve these problems. It's a big burden to bear, and more often than not, building something that will bear such a burden just kills it outright (cf... xmpp.)

<comment><USER32> > "But the only thing that can be done is work on an actual protocol that will > solve these problems."

What about the Matrix protocol (referenced in other comments made in this discussion)?

<comment><USER15> I am following it from afar. I don't see how it'll gain traction, ever, though. The marketing problem is one devs don't like to solve, but it has to be solved.

<comment><USER19> The plan for marketing it is:

* Ensure there are glossy Matrix-native clients out there with a Slack-equivalent level of good UI and UX (e.g. [http://vector.im/beta](http://vector.im/beta))

* Build bridges to federate together as many different protocols as possible. This includes IRC, Slack, XMPP, SIP, Lync, Verto, Respoke etc. We're trying to make this as easy as possible by providing some high level building blocks like [http://github.com/matrix-org/matrix-appservice-bridge](http://github.com/matrix-org/matrix-appservice-bridge). This hopefully will make it easy for others to bridge themselves into Matrix once we have critical mass.

* Release a stable version of actual Matrix standard itself, keeping it as simple but capable as possible. (Right now it's not frozen, and it's still in beta)

* Provide a really capable reference server implementation. (The current one, synapse, is a good starting point and works well for experimenting with Matrix, but we still have work to do on performance and scalability).

* Run around the world encourage existing projects/networks/solutions/developers to get involved and defragment their comms - a bit like the early internet guys had to do with defragmenting email.

It's obviously hugely ambitious, but we actually have some good traction already (despite still being in beta). Hopefully the trend will continue!

[Disclaimer: i work on it]

<comment><USER15> Best of luck! I'll do my best to support you.

</comment></comment></comment></comment></comment></comment><comment><USER33> Completely agreed. I love Slack and it makes sense for a lot of things, but not for FOSS projects. If you're looking for a great IRC Client look into IRCCloud[1]. It has a really nice and easy-to-use interface plus it allows you to be always logged in, just like with Slack.

[1]: [http://irccloud.com](http://irccloud.com)

</comment><comment><USER34> It's not as simple as "just use IRC". Even in cases where an IRC channel is both available and relatively well-promoted, some communities still seek out other tools. The first example that comes to mind is Reactiflux, a rather large React.js community that recently moved from Slack to Discord[1][2], another closed source app that will probably stay that way[3].

To me, the fact that a community of tech-savvy _developers_ won't use IRC exclusively is a pretty good indication that IRC is not enough.

[1] [https://facebook.github.io/react/blog/2015/10/19/reactiflux-...](https://facebook.github.io/react/blog/2015/10/19/reactiflux- is-moving-to-discord.html)

[2] [https://github.com/reactiflux/volunteers/issues/25](https://github.com/reactiflux/volunteers/issues/25)

[3] [https://twitter.com/discordapp/status/648379244570013696](https://twitter.com/discordapp/status/648379244570013696)

<comment><USER35> For context, we've always promoted IRC for real time communication on React. I encouraged people to setup other mediums for communication and many people attempted but only one took off: Reactiflux on Slack. The official way is still IRC on the website but most people are using Reactiflux which is pretty incredible.

Now, we got the bad news a month ago that we've been kicked off of Slack :( So, I started looking at all the options and frankly, all the alternatives I tried had a really bad user experience. Sure, they had all the features of Slack but the polish was not there.

Until I randomly stumbled upon Discord, a chat app for gamers. It turns out that it does everything that we used Slack for, has better perf than Slack... Before we even made the switch officially, people were already using it organically in favor of Slack which is a testament of its qualities.

I highly recommend using Discord for your open source project!

<comment><USER36> It also seems the Discord web client is built on React, which is oddly satisfying. Having trouble finding more info on their stack.

<comment><USER35> "@discordapp: @DenisIzmaylov Our backend is a mix of Python+Elixir/Erlang+C++ depending on which piece of the infrastructure.

@discordapp: @DenisIzmaylov do you mean our encryption? If so, it varies by which version of DIscord you use. TLS, DTLS, and xsalsa20.

@discordapp: @DenisIzmaylov TokuMX and Redis, moving some things to Cassandra"

[https://twitter.com/denisizmaylov/status/656181143205773313](https://twitter.com/denisizmaylov/status/656181143205773313)

</comment></comment></comment></comment><comment><USER37> Slack is the wrong choice for large community projects for one pragmatic reason: the 10,000 message limit for free teams. I participate in a large developer community that lives on Slack. Conversations are deleted quickly on less active channels like #lisp or #volleyball, sometimes within a day. This is frustrating when trying to connect to like minded people and also maintain a record and resource for community members. And at $6.67/user/month it really isn't viable to upgrade.

I can't speak to the quality of projects like Mattermost [1] and Zulip [2], though I'm excited by their concepts. IMO trying these, or using a hosted service designed for community projects like Gitter [3] are necessary alternatives.

[1] [http://www.mattermost.org/](http://www.mattermost.org/) [2] [https://www.zulip.org/](https://www.zulip.org/) [3] [https://gitter.im/](https://gitter.im/)

<comment><USER38> Yes, the 10k limit kills it. After that you can still search old messages and find them but you lose the context because you see only a few lines around them. Either your FOSS project has a budget to pay Slack or you're bound to lose any valuable knowledge and decision buried in the archive.

</comment></comment><comment><USER39> > Problems with IRC that Slack solves

Main thing that Slack solves as far as I'm concerned is a great and uniform client on every platform.

Don't get me wrong, I love irc. This is where I started learning everything I know about computer.

I tried many times to get various team on it and it always failed. I think it's mainly because the learning curve is too big for non-technical/busy people, and that there's no good and uniform clients on all platform.

<comment><USER40> I think this is a really important point. What Slack solves -- speaking in the general case, not specifically for FOSS projects -- is that it's an essentially out-of-the-box solution. Not just for non-technical users, although that's very important, but for _all_ users.

Both the linked article and the various suggestions in comments give all sorts of IRC-based alternatives to what Slack does, but they're all things that, let's be honest, require a lot more work to set up and are often far more fiddly to use. "Oh, this is easy, just run daemon X for this functionality and daemon Y for this functionality, and set them all up using stuff you can get here, here and here. Wait, that last one is out of date. Try using this gist instead. Okay, now, you can get that client-side feature you want if you switch to a different IRC client, use the following .config file, and look for the following plugins, although you'll probably want to change the defaults..."

Compare this to Slack, which for most users is: sign up, click here, and in Jeff Goldblum's words, "There is no step 3." From a practical standpoint you have to install _zero_ new pieces of software (assuming you already have a browser), you have to edit _zero_ fiddly text files, you need to install _zero_ Perl scripts. Once your IRC is set up it seems "easy," but it's possible to spend an inordinate amount of time finding the answers not to questions like "how do I get snippet previews of links to show up in the client like it automatically does in Slack" (the answer is probably that you do not), but questions like "how do I get all the nicknames to show up in different colors?"

For certain FOSS projects, this may be less of an issue because the team may be more experienced in setting up frankly fiddly Unix software, and I think having an IRC channel is a good idea. It may be all you need; what Slack gives you above IRC is generally "nice to haves" rather than "must haves." But the FOSS crowd, to make a very rough generalization, often tends to deprioritize "nice to haves" to a point where they miss, well, just how nice it really is to have some of them.

<comment><USER41> You're absolutely right. But it's sad that comments like this even need to be made. Like people constantly forget that usability is a thing and not everyone has infinite free time to burn on setting things up.

<comment><USER21> ..especially for open source. Increasing the time barrier/complexity just to chat is a big turn off. I already use Slack for work, so adding FOSS projects would be easy. But if I have to fiddle with chat, that's time I could be coding or doing something more productive.

This whole discussion is similar to that Ogg vs MP3 file nonsense on Wikipedia; the victory of philosophical purity over practicality and usability. I still can't just click a Wikipedia sound file on my iPhone and have it just work. Victory for ideological purity big fail for the 98% of the world that doesn't give a s--t about file formats or Jimmy Wales's religion.

</comment></comment></comment></comment><comment> vezzy-fnord The people who clamor about IRC's death evidently don't spend much time in FOSS communities, especially system software. It's absolutely pivotal in those areas.

</comment><comment><USER42> I find it surprising that everyone apparently thinks that it goes without saying that Slack's interface is superior to other choices.

It is full of visual noise. You end up in desparate need of splitting most types of information streams in separate channels because of it, and then before you know it, you're channel-hopping all day long.

For core functionality - chatting - I've found that most IRC clients I've used are superior to it. Hell, even Facebook's chat is superior.

It'd take fully redesigned fully native client idiomatic to every platform abounding with customization options to make me take a stroll through that garden. Not web client and especially not some Electron (is it?) desktop client that looks more like afterthought than carefully crafted experience.

</comment><comment><USER43> Come to the Matrix! [1]

\- Open! Free on both the beer|culture axis!

\- Modern! (There's actually control structures in the protocol. Imagine: a chat protocol that's actually ascii safe! (Yes, yes, unicode too: the joke is, _IRC isn 't even ascii safe_.))

\- Many platforms! (The matrix.org site has a full client list; I'm personally using it via a linux desktop client (that also works on windows and mac), the web, my ipad, and my android phone.)

\- IRC bridged. (I use it _constantly_ in this mode. It's a better IRC experience than any other IRC client I've used, honestly. Even in rooms with 100s/1000s of people. Consistent logs, instantly accessible from multiple computers/clients, no need to set up bouncers, and so on.)

\- File uploads, images, videos. All of it. A friend streamed me a video from his halloween party last night via the Matrix client on his iPhone. It worked.

\- Did I mention it even supports webRTC? That's right: it's also a completely functional skype replacement. (Yes, pending your browser's support and all that jazz: that said, it's a more complete product than most of the other webRTC demos floating out there.)

The entire protocol is just... _good_. On the nerdier deep end of things: It's the first federated chat standard I've seen proposed that actually has reasonable message IDs baked in and loose timing systems that's both available during a partition and can reach consistency afterward (messages list their last-seen messages, and so act like vector clocks, an accepted good solution to problems in CAP territory). You could actually take two systems with clock skew and have them reach a single, reconciled view of the world, even after netsplits. Compared to IRC (or XMPP) this is either magical or a deep relief, or both.

I discovered Matrix while I was in the process of writing a chat client of my own for XMPP. I abandoned the project (and XMPP, as well, though that's a subject all its own [2]). Matrix already did everything I ever wanted. Really, really well.

Not affiliated; just a happy user who's never found any better platform for communicating openly.

\---

[1] [https://matrix.org](https://matrix.org) | [https://vector.im](https://vector.im)

[2] [https://news.ycombinator.com/item?id=9772968](https://news.ycombinator.com/item?id=9772968)

<comment><USER44> +1

matrix solves a lot of problems that IRC has and even lets you solve those problems on IRC through the Matrix<->IRC bridge :)

I've been using it as a replacement for my IRC bouncer for a while, barring a bug that prevents support of SSL-only rooms, and it's been wonderful. Great web client on vector.im, pretty decent mobile clients given they are "reference implementations", support for VoIP voice and video chat, coming support for e2e encryption (the DAG just stores encrypted blobs now)

I've long felt that a big piece of my love of IRC was the spontaneous intersections of my communities. I got involved in FOSS and open source because one time a person mentioned there was a LUG chat for the city I was in; that led me in to a long chain of events that ended with me getting involved in the Fedora Project and other FOSS communities. Slack is creating a world where that is simply not possible. One of the big things that this discussion misses is that tribal-intersections that IRC allows opens up a huge door for abuse. Slack "solves" that by siloing you away from the world, but that has always been a lazy and error prone solution.

I feel like Matrix is in a position to move the needle on that. It's got a huge distributed DAG specifically designed for human-metadata like chat and presence and, well, why not put Karma or Reputation on that DAG as well? People have talked of dogecoin and similar as a Whuffie ([https://en.wikipedia.org/wiki/Whuffie](https://en.wikipedia.org/wiki/Whuffie)) and in my mind Matrix is an interesting platform to build something like that on. I could create a room that requires a certain reputation level to post in, and you'd have to gain reputation in other communities to be allowed to post in to mine. When you realize that Matrix.org 1:1 chats are just "rooms with only two people in them" that becomes a really nice way to solve the spam/abuse issue. Prove to my friends in the public chat that you aren't a shitbag and you can talk to me.

</comment></comment><comment><USER45> This post is completely disregarding the ease-of-use of Slack (and other silo'ed chat rooms), mainly due to it's pretty monolithic structure.

Yes, there are many things that Slack does that _can_ be done with IRC, but they require significantly more coordination between various parts than Slack. I'd love to see an alternative to Slack not just a clone, as easy to use and administer, and built on an open protocol. Individual teams should be an easy entry point for a tool like that.

</comment><comment><USER46> I will add one silver lining to all of this (since I agree with everyone talking here that IRC is "hard"), Slack is also hard. That is to say, we're still in low hanging fruit phase. I don't know if I was just _doing it wrong_ , but when I had to join the Slack channel for a FOSS project, I found it very confusing:

1\. I had to be invited or something? (Still don't know if this is the case always)

2\. It still remains a mystery to me exactly how Slack treats different accounts (or are they all the same account?) for different projects. It makes me like sign in to them differently but then they all show up together?

3\. The Slack app is great or whatever, but its cool when a project can just embed an IRC channel, and even just make you an automatic account, right inline on their site and not have to deal with signup for _anything_.

If someone wanted to enter this space, they still could. Just make something that allows you to have one "Account" that would work across the board, had an embeddable widget so there's no "going" to the chat, its just there on the project page, has bots and emoji or what have-you. Maybe Gitter is working on this (already has all these abilities?). But suffice to say, I find it funny (sad?) that the discussion is around how easy Slack is vs IRC when IMHO Slack is still pretty hard and confusing.

</comment><comment><USER47> Hacker News: is closed source is a walled garden requires a "Y Combinator" account to communicate

Most people don't use software because of the driving philosophy behind it — they use it because it solves a problem of theirs.

If a tool is the best one for the job, you should use it. And if Slack has a substantially better UI for communication, maybe developers of IRC clients should try to build a better UI rather than complain about adoption of Slack.

<comment><USER18> In all fairness, while the currently running incarnation of HN isn't open, earlier versions of Arc and hn/news (along with forks) is open source, eg: [https://github.com/arclanguage/anarki/](https://github.com/arclanguage/anarki/)

And there are clones, like lobste.rs:

[https://github.com/jcs/lobsters](https://github.com/jcs/lobsters)

Then there's the API, that allows anyone to export data. So while I get your point, and agree with it to a certain extent, it's also not entirely fair.

</comment></comment><comment><USER48> There is a chance to repeat git success story. Remember what happened? 1. Everyone uses cvs or svn. 2. Bitkeeper comes along with a good DVCS, gets adopted by Linux. 3. Linus rants about closedness of BK, reimplements it as git. 4. Git takes life on its own gets wildly popular and makes way for many awesome things such as github and gitlab.

Replace svn by irc and bitkeeper with slack. Figure out the rest.

<comment><USER49> www.matrix.org?

</comment></comment><comment><USER50> Slack is awesome. It's way better than IRC in many ways. But I agree with the OP. Please don't use it for FOSS projects, use it for your company or other private use cases. But FOSS projects an communities require open tools. Slack won't save your history unless you pay for the service. The pricing is per user which makes it very bad for a FOSS community.

</comment><comment><USER51> > I put a lot more faith in something that's been going full speed ahead since > the 80s than in a Silicon Valley fad startup.

That's how I felt during the dot bomb era when I heard that General Electric had been eclipsed in market cap by one of the new startups, Amazon.

Although IRC has an old heritage, it's arcane and user-hostile. To some extent it wants to be that way, to help keep the unwashed masses away.

IRC isn't as easy to use as Slack for things like persistent history accessible from mobile and desktop, and integration to git. That's why alternatives are gaining ground.

If this situation bothers you ideologically, there's actually something you can do! You can help open source alternatives be as easy to use and integrate as Slack is. If your goals are less ideological and you just want your team to immediately get on the task of solving business problems, consider Slack.

</comment><comment><USER52> Amen. To add to the list, there's also Bitlbee ([https://www.bitlbee.org](https://www.bitlbee.org)) that acts as an other protocol (AIM, MSN, XMPP/Jabber, Twitter, etc.) to IRC translator, so you can consolidate all your short messaging into one IRC client. The ZNC + Bitlbee combination is quite powerful.

Additionally for iOS users, there's a push notification client available for ZNC, which is pretty handy.

</comment><comment><USER53> IRC kind of sucks. The experience is worse. That's why people keep making these different tools - Campfire, HipChat, Slack.

It's not just a technical thing. It's an experience thing. IRC is technically fine, just way too nerdy to be main line of business software these days.

<comment><USER54> So what you are saying is that the client software is not intuitive.

You do know that all that needs to occur is to make a nice client?

<comment><USER55> Sure. "all that needs to occur" is pretty useless if it hasn't occurred.

<comment><USER54> Which means IRC itself doesn't suck, only the UIs we have made so far.

</comment></comment></comment></comment><comment><USER56> I can't agree more with this headline. I can concede that IRC isn't the most modern of technologies, but it is effective and well-developed at what it does. There is a FOSS ecosystem that can be achieved with IRC, which cannot be achieved with Slack. As a FOSS project, you can commit to only using free and open software when you also use IRC, as software such as atheme or charybdis are all open.

Additionally, Slack is more privatized, with a less opportunities for enhancement (e.g IRC bots, IRC webchat, many clients). All users also need to sign up prior to use, which is just simply not viable. IRC manages large influx of help-seekers or project members well with its op-voice-user and ban/quiet system, allowing for channel operators to handle the high amount of users without a problem.

On the other hand, Slack fails at all of these points, as it is intended for internal team usage and struggles with this specific usecase.

Furthermore, most FOSS contributors are also not contributors to a single project only. For instance, I personally contribute to a variety of FOSS projects, and it is extremely easy for me to coordinate with all of those projects simply by opening a new channel on my freenode or OFTC network in my IRC client. Slack lacks this, requiring a new tab for each project and really lacking support for FOSS operating systems such as Linux distributions, a problem that is likely not going to be fixed due to its closed-source one- client structure.

</comment><comment><USER57> I hate irc. I hate it for one main reason, nobody uses it. Now, before you say "over x million users" I mean use, like I actually talk, not just sit there logged on. I have tried to join a lot of open source or product channels on irc (pypi, python, docker, wercker, kubernetes, etc.) And every time without fail, I join the channel and there are over 50 people signed in and I'm like "awesome people actually use this channel", then I proceed to ask the question the prompted me to lognin in the first place. After four hours and no answer or response at all, I usually have to go home, or shut my computer down. I don't have a desktop running 24/7 just so I can irc. So once I log off, I know I'm never getting an answer. I might try again if I have another burning question, but with a couple of tries and no luck, I eventually give up.

Now slack on the other hand I've never had this problem. I don't know what it is, but some of the same communities switched over to slack (i.e. kubernetes) and once they were on slack, I was getting responses and discussions from multiple people within 15 min or less. The beauty is even if the channel wasn't as active it would still be a million times better because I can shut down my laptop, and get notified on my phone when someone replies. I can then continue with the conversation publically or privately, even if the two of us are on other sides of the world, because history is saved and I don't miss anything I'm notified on, even if I'm not logged in anywhere.

</comment><comment><USER58> I know of at least one tech company using slack as a support channel. It's not a great experience for the user at all. I love slack as a company communications platform but I totally agree that it's not well suited to being used as an open communications platform.

</comment><comment><USER59> At Qbix (our company) we believe that there will be a platform for social apps the way that Wordpress is for blogs.

We just recently met with a VC who was impressed with our platform pitch, saying he hasn't seen something large in our space that's open source yet. Slack specifically came up as something that Andreessen Horowitz made a big bet on. I'm not going to say much (unless someone asks) except that:

* It's open source and on GitHub ([http://github.com/EGreg/Platform](http://github.com/EGreg/Platform))

* It is designed to put control back in people's and communities' hands. It should be installed by communities, or they can choose us to host, like wordpress.com does

* Each community can release its own client app, BUT you can also have client apps which provide a seamless experience ACROSS communities and let you do identity + connect with friends + get notifications across communities!

* This was not easy to build. It took us over four years.

We started before Diaspora* and we built an open platform on which app developers can build apps which communities can install, and which can aggregate social experiences across communities. The apps can be ANY social apps and the platform takes care of all the underlying details, including app versioning, user identities, "finding your friends" in each new community, registration/password stuff, email / mobile notifications, native app integration and caching, and much more.

</comment><comment><USER60> IRC? Really? That's your solution? Not some kind of self-hosted Wave-like tool or something? Not something web-based?

<comment><USER18> Technically, there's no contradiction in using IRC and something "web-based" \- there are a number of decent IRC web clients.

</comment></comment><comment><USER61> To add to this, don't use Gitter for FOSS projects either. I've been seeing lots of projects abandon IRC for Gitter.

<comment><USER62> In addition, Gitter is open source, has many client apps and, it, or really need, a irc bridge

<comment><USER18> I'm sorry, the Gitter server part is open source? AFAIK it's a closed source service?

</comment></comment></comment><comment><USER63> It seems that the author is following his own lesson faithfully:

[https://www.reddit.com/r/programming/comments/3r3m6q/please_...](https://www.reddit.com/r/programming/comments/3r3m6q/please_dont_use_slack_for_foss_projects/cwktw5j)

</comment><comment><USER64> I'm responsible for a medium to large FOSS project. I noticed that Wordpress had recently moved to Slack, and asked someone I knew over there how engagement had changed after the move.

He reported they saw about a 10x increase in users moving to Slack (100 -> 1,000). ([https://twitter.com/HypertextRanch/status/627122747664113664](https://twitter.com/HypertextRanch/status/627122747664113664))

I get the arguments about not using it, but my priority is providing the best tools to the community to enable them to work together productively, as well as providing the most effective forum to encourage more people to get involved. How can I ignore that sort of order of magnitude increase in the number of people who can engage in real-time with the project?

<comment><USER65> I've heard the Wordpress tale and I would guess that it's more related to the announcement and press around it generating attention than it is the merits of either platform. A lot of people who didn't know Wordpress had a chat room probably joined up.

</comment></comment><comment><USER66> Completely agree with this. We use Slack for our Business Communication and love it, we pay for it so we can see all our messages and it definitely has its place. (Office Managers, Project Managers, Directors, PR are all in it, super simple and easy for them)

For Open Source projects or just general communities IRC is the best medium suited to it. Yes IRC has its issues but maybe that's because no one has brought it forward with the kind of velocity other projects seem to have these days.

I don't boycott Slack teams I just find it difficult to manage more than 2 teams in the client so I just don't, I like channels in IRC. I can flip between them regardless of server or team and can see the entire history.

</comment><comment><USER67> Scans as a case of the "I like X better than Y, therefore X is objectively better than Y" rationalization fallacy. Someone else could easily use the same set of facts to argue the opposite case: "irc doesn't support code snippets, so ....". The political argument that you shouldn't use a closed-source product also irritates me. I use a tool because it's the best tool for s job, and FOSS is very often the winner there. But if the FOSS option isn't the best choice, don't tell me I should be using it anyway. I don't attach moral weight to a choice of licensing model.

</comment><comment><USER68> Are any particular irc networks recommended for FOSS collaboration? I'm guessing channel and Nick services should probably be a prerequisite but other than that, where do people prefer to congregate?

<comment><USER65> Freenode.

[http://freenode.net/](http://freenode.net/)

</comment></comment><comment><USER69> Main problem with IRC is that it's not "always on" and I really need this feature. Sure you can use IRCCloud or SSH/Screen into a server, but they both cost money while Slack is free.

<comment><USER65> How is Slack free? You have to pay per user or apply for an exemption if you are a non-profit. IRCCloud is free by default and you only pay to unlock some extra features.

[https://slack.com/pricing](https://slack.com/pricing) [https://www.irccloud.com/pricing](https://www.irccloud.com/pricing)

<comment><USER69> Slack is free, we use it for free and it's always on. IRCCloud's free service disconnects after 2 hours of inactivity.

</comment></comment></comment><comment><USER70> Are there IRC clients that work well in poor connectivity situations?

I.e. does IRC or any IRC client support sent, received, read confirmation the way that What'sApp or Google Hangouts reports this information?

<comment><USER71> With a properly configured bouncer (ZNS is rather easy to setup), it will work regardless of the client.

</comment></comment><comment><USER72> Completely agree! I see free software projects depend on proprietary tools _all the time_ and it is very frustrating. I often see projects using JIRA or asking companies like JetBrains for gratis licenses to proprietary development tools, and now I'm seeing Slack more frequently. I _will not_ participate in your free software project if you depend on SaaSS or proprietary software to get work done.

The company I work for uses Slack, and luckily there is an IRC bridge to connect to so I can keep my workflow in Emacs rather than having to use a clunky web interface, but there are many special Slack things that they don't render correctly in plain text form so I feel like a second-class citizen. If this is the future of text-based communication, I don't want to participate.

I like IRC. I like that things aren't centrally logged by default. I like the bots that I've been interacting with for many years (that I find to be better than whatever Slack bot I've come across, by the way.) I like Freenode as an IRC network. I like the variety of clients available (I prefer ERC, a client written in Emacs Lisp.) Could we use some sexy web clients to get less technical people on board? Sure! Should we use a proprietary, centralized, surveillance system until someone else fixes IRC issues for us? No way! We must reject Slack because it isn't a tool for the people, but a tool for profit.

<comment><USER30> What makes you think IRC isn't centrally logged? You realise that the Freenode staff have root on all Freenode servers, right? It's not actually a decentralised network at all, it just looks superficially like one from the outside: they could log whatever they wanted at any time.

I'm not even sure the servers use encryption between each other. If they do I didn't see any mention of it on the freenode website.

Heck, given that SSL isn't even a default for many IRC clients, I suspect that in practice it's vastly easier for governments to eavesdrop on IRC than on Slack which is fully SSL, always.

<comment><USER73> The software is very simple and doesn't have the ability to log messages like that. I maintain a fork of the ircd freenode uses and that simplicity has actually been a bit of a pain as things grow.

</comment></comment></comment><comment><USER74> Isn't another huge thing that Slack solves the need to set up a local client? Why is that not addressed in this article, I wonder if the author really doesn't see it as a problem?

<comment><USER58> There are lots of web-based IRC clients out there

<comment><USER39> Which is part of the problem. People don't want "a lot of web-based IRC clients", they want only one and it has to be amazing.

<comment><USER54> The things slack can do (at least according to this article) that IRC can't are do small it's negligible. If slack is web-based, then what is to stop someone from making a web-based IRC client with all the features and good UX design of slack?

<comment><USER75> And there is: [http://shout-irc.com](http://shout-irc.com)

IMO Shout is a UI improvement over Slack for the sheer fact that it is 100% customizable.

<comment><USER54> You realise you just increased traffic on their demo by like 1000%? :-)

Pretty nice though.

</comment></comment></comment></comment></comment></comment><comment><USER24> One thing even private organizations should think about is the potential for chats on Slack to embarrass the heck out of them. Slack doesn't let an organization sunset and delete private chats/DMs after a certain amount of time. When employees think they aren't overheard they start to get very frank with each other (which is good, I think frank and direct communication is important). But sometimes they say things that are ignorant or even their frankness can reveal things about the company that are embarrassing. This isn't even a theoretical scenario anymore, look no further than dumps from recent hacks.

I like Slack's default-to team member privacy but you can implement these features without compromising that. I opened a case with Slack about it but they closed it with the standard "consider it in the future" response that I expected (which I don't hold against them, I can't say I wouldn't have done the same). It may take a breach of Slack's infrastructure and subsequent leak of private chats for them to make the changes needed for organizations to protect themselves from this.

It might only take user education to protect a company from this, but in the end if you're a big enough organization there are going to be people that don't care, hate the organization or are just to jaded to take the ramifications seriously.

<comment><USER76> Looking at this page it seems entirely possible to configure a DM retention policy: [https://slack.zendesk.com/hc/en- us/articles/203457187-Settin...](https://slack.zendesk.com/hc/en- us/articles/203457187-Setting-up-custom-message-and-file-retention)

It seems to by default use the team retention settings.

<comment><USER24> Thanks a bunch for this. I'm surprised the person helping me didn't know about this (unless it's fairly new) but I should have put more effort into researching it myself.

</comment></comment></comment><comment><USER77> I think it's perfectly fine for FOSS projects to use non-FOSS. This article is a wee bit on the fanatical side for my taste, and I'm the guy who bought the lemote. ;)

A public FOSS project should be able to use whatever they want for bug management, issue management, support, and other things that do not affect the core project in any way if compromised or monitored.

Especially if the company behind said product even give out discounts or free usage accounts to such projects like Atlassian or github.

</comment><comment><USER78> Yeah, IRC clients are hard to use, too many are command-line based, although on Linux you can still find a few with GUI, but not as pretty as Adium on Mac OSX. Your mileage may be different, but when I was working at Mozilla everyone used IRC and it was not a huge burden because most people really just do /join or pm a person. As long as you provide a documentation on how to use IRC, you are golden for the most part. If you mandate people to use IRC and have resource available to help troubleshoot or setting up IRC, you are good. If you need to set up some complicated things with IRC, well, it is tough, but you are on your own.

Slack's interface is not very impressive, very messy in my opinion, but that's me. There are businesses out there offer IRC as a service, so that's another option.

Final point: I really don't care about FOSS vs OSS vs Proprietary. As long as the company truly respects my data privacy and security, and is easy to use, I can give zero damn about either of three. It's 2015, we need to stop arguing and actually make things better. Business needs to focus on improving product experience and security. But you know what, some people do, that's fine, none of my business anyway.

</comment><comment><USER79> Been a heavy IRC users in the 90s, no a Slack user. There just is no comparison for me. Do I miss channel wars, nickbots, take overs and hacks? No.

</comment><comment><USER80> If you want to communicate with a person or organization in ways that don't involve online chat, you have a variety of standard ways for doing so:

\- E-mail address

\- Phone number

\- Mailing address

What is it about chat protocols that has resisted convergence on anything as remotely standard as these other methods? I mean, I _could_ tell somebody that I spray-painted hieroglyphics on my house and that "there are 3 shipping companies in the world that know how to find my house using hieroglyphics so please ship through one of them", yet somehow my "address" has remained the sensible way to handle that problem.

The problem isn't Slack or IRC or any other client, it's that _we have any choices at all_. At this point we don't _need_ choices for chat protocols any more than we need a choice of ways to put an address on a house. The technical community needs to start loudly criticizing clients that aren't converging on _some_ standard, and standardize more and more behaviors every year until it really doesn't matter what people are using.

<comment><USER81> So, in the US:

> \- Phone number

Originally supplied through a monopoly.

> \- Mailing address

Government assigned.

> \- E-mail address

Originated on a government funded and used network, but eventually settled on open standard.

Having the ability to impose usage until a critical mass is achieved and being first seem to both be criteria.

</comment></comment><comment><USER82> > has only one client

I haven't used Slack's Gateway feature [1] but it seems Slack does allow you to connect with standard IRC and XMPP protocols.

[1]: [https://slack.zendesk.com/hc/en- us/articles/201727913-Connec...](https://slack.zendesk.com/hc/en- us/articles/201727913-Connecting-to-Slack-over-IRC-and-XMPP)

<comment><USER83> It does but you lose a lot of little features that other people using Slack will expect you to have and be able to see/interact with.

</comment></comment><comment><USER84> Anyone here tried [https://botbot.me/](https://botbot.me/) for logging?

</comment><comment><USER85> Agreed. No more proprietary IM services please.

</comment><comment><USER86> While we're on it, can anyone recommend a good open source calendar app with decent web and mobile interfaces? (if there is one)

I'm building internal tools for the record label I make music with. We're going to try self-hosting Zulip vs. Mattermark for collaboration, and it would be great to have a calendar that integrates well.

</comment><comment><USER87> Slack is starting to be used as the communication platform at events now as well. Most of the hackathons and conferences I've attended recently have used it and added all of the attendees.

It's worked really nicely for communicating announcements and updates with the added benefit of allowing attendees to socialize before, at, and after the event. It's also really changed how things like mentorship are done [0].

The problem I've had is the lack of any form of SSO. With all the events, FOSS projects, and actual organizations I'm up to 19 Slack accounts. Having to signup and create a new account almost every weekend is getting crazy.

[0]: [https://medium.com/mhacks-hackathon/hackathon-mentorship- can...](https://medium.com/mhacks-hackathon/hackathon-mentorship-can-be- better-425d9a190ce4#.92mrjzcjg)

</comment><comment><USER88> I've used IRC a lot. For work and for projects. The experience is always horrible, and the clients always suck. We switched over to using slack for projects and for work and everything got instantly better. It takes seconds to setup and destroy places to chat that are private. It also takes seconds to search your entire history, on any device, and find what you talked about 3 weeks ago. Sharing code that doesn't get removed is amazing. It's a pain in the ass when the IRC client removes code and tells you nothing. I've sent entire messages to people which "get blocked" because the message is too long or contains code, and it never gives feedback.

I agree account creation in slack sucks though, and the author is correct that slack is not built for FOSS projects.

</comment><comment><USER89> If IRC's limitations are too cumbersome to workaround there is also XMPP.

<comment><USER15> IRC's limitations are not those fixed by XMPP.

Previous discussion on this: [https://news.ycombinator.com/item?id=10280611](https://news.ycombinator.com/item?id=10280611)

</comment></comment><comment><USER90> None of the problems listed seem like problems to me. All of the solutions that make IRC fill this role seem like they will require more work and time to set up than I am to put in just to get communication set up. Slack just works. So unless I am going to be working on something highly sensitive that I can't trust a third party reading about, I'm going to keep using it.

Wouldn't the best solution be to adapt one of the existing open source slack clients to use a local server? Then we have all of the feature set and none of the security and privacy concerns.

</comment><comment><USER91> We use Slack to support the open source development for Convox (open source PaaS). The main benefits are:

Mobile client with push notification

First class photos, files, code snippets

Moderation tools

Same tool for private organization chat

Users that use Slack for the jobs seem to really like Slack for community support

The downsides are:

No invite system. Needs an hack app

Unsupported use case for community chat

Closed system. Exclusionary compared to IRC

So far the productivity gains feel worth it. I can only guess Slack doesn't mind this usage will provide better public chat offering someday.

A few people have given the same feedback about using IRC over Slack, however so it's on my mind.

Would chatting in both work?

</comment><comment><USER92> \- The Slack client is an improvement over IRC ones. I don't remember free IRC clients (GUI) for Mac OS or Windows (there's Pidgin, but still...)

\- File transfers and snippets are not so essential, but they make working simpler

\- You can connect to slack using IRC or XMPP [https://slack.zendesk.com/hc/en- us/articles/201727913-Connec...](https://slack.zendesk.com/hc/en- us/articles/201727913-Connecting-to-Slack-over-IRC-and-XMPP)

<comment><USER93> HexChat is a pretty great free client for Windows. It's basically XChat.

<comment><USER65> HexChat supports OSX, too.

</comment></comment></comment><comment><USER94> I understand the urge of certain people to fight Slack but if you think irc is a legitimate alternative, you probably don't understand the problem enough to offer a suggestion.

More credible alternatives would be Hipchat or Gitter but anyone who has used these two tools know that they are still way, way behind Slack in functionalities and user friendliness.

Slack is succeeding because it's a great tool.

Want to beat it? Create a better tool and people will migrate to it for its merits, not because it's open source.

</comment><comment><USER95> We (sameroom.io) bridge channels/room in Slack, IRC, Gitter, and several other systems (about 14). It's a commercial venture, mainly aimed at helping large companies manage the lack of federation between team chat factions.

However, we do what we can to support open source and we'd be happy to provide sameroom functionality to open source projects. Please reach out on sameroom.io/contact to take us up on the offer.

</comment><comment><USER96> Do I sound backward if I thought it was about Slackware?

</comment><comment><USER97> Fact: IRC doen't persist chat messages on the server, so to view old messages you need to install a bot that provides you with the last n messages... and you have to manually query the bot for them. No thanks. Have you people heard of this thing called "mobile"? Spotty connections are the new normal. Having the last N messages autoloaded when I view a channel is a _necessity_.

</comment><comment><USER98> I agree to most of the points you make, except that none of those points would work in real world without a LOT of effort.

I've summed up my thoughts on this topic here: [https://medium.com/@kumarharsh/please-use-slack-for-foss- pro...](https://medium.com/@kumarharsh/please-use-slack-for-foss-projects- bf9d53ce3f7d#.ea6xotd8m)

</comment><comment><USER99> I hear a lot of people talking about the problems with IRC, and I truly wish someone would enumerate them. It works great for our needs but I'm very curious the ways it isn't working for some.

We use a self hosted IRC server, along with an IRC bot written in Go for everything from automated deployments to chat logs to weather and traffic and bus schedules.

</comment><comment><USER100> I run a large FOSS project; we use both Slack and IRC. Working with maintainers in 3 or 4 different timezones you can't afford to lose your IRC session if you don't want to miss messages. As pointed in the article however Slack is for _teams_ , not _communities_. We use IRC for open discussions and keep internal discussions on Slack.

</comment><comment><USER101> Some of the features mentioned here: persistent log, powerful search, comment editing, easy onboarding and invites, code blocks; some even ask for thousand of users in a chat room and moderation tools! Wouldn't this communities be better served by a modern forum, like Discourse instead of a chat?

</comment><comment><USER102> > requires users to have a different tab open for each project they want to be > involved in

This isn't true, down the left side bar you can select other teams if you've signed into more than one.

I'm not suggesting we should only use slack, but at least they do make it fairly easy to navigate.

</comment><comment><USER103> I just also want to make the argument that github is a walled garden, so is google code. They're proprietary systems that we're able to use and take advantage of. I use github and I love it, but it can still have the same potential issues as slack.

<comment><USER65> I don't think that's true. GitHub is a frontend for the open git protocol. You can take your repositories and move somewhere else with next to no effort. Heck, almost all of my repositories exist in multiple situations.

All that being said, I've personally been doing more things on a private git server and less things on GitHub.

</comment></comment><comment><USER104> I think you would be better off using a full fledged forum. Then use a chat (IRC or whatever) on top of that for real time communication. Where the important stuff goes to the forum, and general talk in the chat.

</comment><comment><USER105> Just wondering here can someone explain to me why campfire didn't move to fill the need of IRC/slack better? was it ever truly competitive in this space?

I was casual fan of 37 signals/Basecamp.

</comment><comment><USER106> I don't use Slack because they had a significant security breach and I'm not convinced they are doing things differently or better since then.

</comment><comment><USER107> I've noticed many hosts call out IRC in the TOS, as IRC is prone to DOS attacks.

And is there Giphy integration? Or editing of posted comments?

</comment><comment><USER108> I hadn't even heard of Slack before this article, but definitely IRC. Perhaps it would be opposite for the newer generation?

IRC is also my preferred protocol for realtime messaging, for the reasons mentioned in the article and also the fact that it's _extremely simple_ \- you can even use it with nothing more than a network terminal like netcat. My second preference would be the older versions of MSNP (before they started stuffing XML into everything...)

</comment><comment><USER109> [http://gitter.im](http://gitter.im) is well suited for github projects!

</comment><comment><USER110> Nothing to see here. Just another engineer who is so obsessed with engineering they think UX doesn't matter.

</comment><comment><USER111> Unfortunately, you managed to pull off a Streisand. So... what is Slack? And where can I use it? Sounds useful.

</comment><comment><USER112> Wouldn't Slack be ideal for FOSS projects? My fear would be of losing sensitive data when using Slack, but with a FOSS project this isn't an issue.

Slack is a tool, like a debugger or IDE, which aren't all open source.

If you are working on a government project with secret clearance, then these issues make sense. Otherwise, the article feels like it has more of a "whippersnapper" message.

<comment><USER113> I disagree with some of the things in this article (mainly that IRC is necessarily better for your company) but Slack isn't _ideal_ for FOSS projects. It's a very long way from ideal.

Main reason being: Slack is a company and as such they can change their policy at any time. There isn't any specific right granting FOSS projects any status. Slack can ban the users they want, can deny access to accounts they want, they can be sold to other companies and can be bankrupted, bring it all crashing down.

Slack isn't a tool, it's a service. It's not in any way whatsoever like a debugger or IDE, even if those may be closed source. A tool is something you have and can use. You might not own its manufacturing but you own its potential use. Like a hammer you didn't make but is yours to do anything with. You can use it a million times if you want.

Slack is someone else's hammer that you pay to use. That's a service. The fact that they allowed you to use it for free for some undefined period of time doesn't mean you own it or dictate any rule of its use. It's still their hammer. They can stop you from using it at any point in time.

FOSS projects are supposed to be inclusive, open, transparent and fully decided by an owner or a community. Giving away control to a third party with no contract whatsoever is a terrible idea and a good way to break many of those premises.

Slack is being used for FOSS because of the failings of IRC noted by others in this thread, but that doesn't mean it's a good idea. Certainly not when the audience for Open Source is already very accustomed to IRC.

Slack is great for the turnkey solution it is, it offloads that IRC configuration you'd have to do, and it's easier to introduce non-technical people to. It's good for paying customers that have a clear contract with the company and as such gain certain rights. It's not, in any way, ideal for other cases. It might fit them, but it's not a great idea.

</comment></comment><comment><USER114> I am surprised nobody mentions Jabber, it is better alternative to Slack than IRC

</comment><comment><USER115> using irc on a daily basis, I wish it supports some basic tags such as <pre>, <code>, <img> and <video>, to make it more like a html chat IM...but anyway I like it and use it all the time.

</comment><comment><USER116> Honestly I still prefer irc

</comment><comment><USER117> And same goes for hipchat.

</comment><comment><USER118> And yet the author links to his Github profile.

</comment><comment><USER119> Apparently Slack has become the new BitKeeper!

</comment><comment><USER120> Tide, please don't rise.

</comment><comment><USER121> What about gitter.im?

<comment><USER84> users need a github account to use gitter.

<comment><USER122> They need accounts for Slack as well. In fact they need an account for _every_ Slack, at least with Gitter you just have to have a GitHub account.

</comment></comment></comment><comment><USER123> IRC and mailing lists and forums is pretty much were open source communities live and work together for several decades.

Competitors want to reach out to such communities and vendor lock-in them. Nothing new, had been tried before with MSN Messenger, AIM, Skype videochat, etc. though IRC will hopefully stay about such waves and fades - it's a rather simple protocol, has a good file transfer mechanism and thousands of native, it cannot be censored (words filtered) and web clients for every platform and needs (incl bots).

</comment><comment><USER124> > that Heroku hack

What is the "that Heroku hack?" mentioned in that article

<comment><USER125> I was also curious about this. As the article mentions, Slack doesn't make it easy for your organization to allow open registration. People have developed hacks around this by running a server on Heroku [0], or using Typeform combined with Slack's API [1].

0: [https://github.com/rauchg/slackin](https://github.com/rauchg/slackin)

1: [https://levels.io/slack-typeform-auto-invite-sign- ups/](https://levels.io/slack-typeform-auto-invite-sign-ups/)

</comment></comment><comment><USER126> I agree Slack is a poor fit for this. But god, using Slack makes it painfully obvious how shitty IRC is. I almost wish people would stop mentioning them together. I hate IRC and I have since the 90s, it's just bad.

</comment><comment><USER127> irc.buttes.org #flashsupport.

tell them tater sent you

</comment><comment><USER128> >That the reasoning is fallacious doesn't make the conclusion incorrect.

This is trivially true by the [material implication, modus ponens, modus tollens, other name, etc] truth table. However, if you study the truth table a bit longer, you will realize that you should stop reading any text which contains fallacious or self-contradictory logic. While the conclusion may be "correct", it is correct _despite_ all of the other text you read (so, go find a logical argument [instead of relying on _known bad_ information]). The text you read _can tell you nothing_ about whether the conclusion is true.

Fallacious reasoning needs to be identified, targeted, and destroyed.

Edit: I've been rate-limited, so any fallacious (or non) arguments posted in response will need to wait a while for a proper response (some have already been typed up).

<comment><USER129> We detached this subthread from [https://news.ycombinator.com/item?id=10487585](https://news.ycombinator.com/item?id=10487585) and marked it off-topic.

<comment><USER128> Care to elucidate the topic and how this subthread was not on it?

Edit: I know it's a lot to ask for.

Heh. Downmods.

<comment><USER129> For HN purposes, an egotistical spat is not on any topic.

If you want to keep commenting here, you need to err on the side of following the HN guidelines rather than breaking them. Your account has a long pattern of breaking them, and of straddling them when not breaking them outright. That's not the discourse we want here.

<comment><USER128> If you can show me the ego, I will concede to being off-topic.

I reject any notion that I have ever intentionally broken a guideline. I also reject any notion that I have a pattern of repeatedly breaking any actual guideline.

My claims are easy to falsify.

</comment></comment></comment></comment></comment><comment><USER130> There's also a hard user limit on free accounts - 5000 iirc.

</comment><comment><USER131> I call FUD. Something to the effect of "Please people, don't drive cars, they are not FOSS". My company pays for Slack and we get a ton of value from it. Kthxbai!

</comment><comment><USER132> This seems to be similar to the argument of "don't use Github or Bitbucket, use your own hosted Gitlab". Some of the complaints are a bit petty (really, an extra browser tab per project is a burden?)

IRC is better for occasional participants that wish to remain anonymous and/or use less screen real estate, but Slack is generally a better experience for regulars and way less hassle than hosting your own server/bots. Ymmv

<comment><USER72> >really, an extra browser tab per project is a burden?

Spoken like someone who has never been a serious IRC user.

<comment><USER132> I used IRC every day for 15 years from high school through work. This is akin to saying having a different tab for each IRC SERVER (not channel) is a burden. I personally prefer having separate tabs for each project, but ymmv.</comment></comment></comment>


Your First Rails App in 10 Minutes - <AUTHOR> https://www.youtube.com/watch?v=4nyzl3pVXp4

<comment><AUTHOR> Hey,

So I was a long-time fan of services like TeamTreeHouse, RailsApps & OneMonth.

I really am a big fan of quality education being available for everyone, and because of that I've opted to open source my CS education on YouTube.

I'm starting with Rails, and I will eventually work around to more core CS topics like circuits -> logic gates -> binary -> assembly -> c -> Data Structures -> Algorithms etc.

If you like it subscribe and I'm looking for all the feedback I can get on how to make it better :)</comment>


Ask HN: What is the Google/Verizon net-neutrality story all about? - <AUTHOR>

Can somebody explain, briefly and in layman's terms, the scandalous pact of Google and Verizon?<p>Was this truly surprising? How bad is it really? In short, what is going on? <comment><USER2> as brief as i can be:

Google has long represented themselves as 'not evil'. Large segments of the tech community bought into it and overlooked certain things that google has done overtime. After all despite various issues, they were a strong proponent of net-neutrality. Basically, that all traffic flowing over the internet should be treated as equal. In addition, they advocated giving enforcement powers to FTC.

Flash forward and Google at some point realized that this wasn't nec. something that benefited them. They were apparently in talk with Verizon for the past 10 months to craft a framework for net neutrality that basically showed that they are in fact a corporation out for their own interests not some altruistic organization that people could project their idea of what 'not evil' is upon.

some basic points from the framework:

the wired internet should be traffic neutral expect where users or network operators are blocking unwanted traffic etc.

that there should be no such rules for wireless but that any traffic shaping etc that telecom companies do should be 'transparent'.

that new services should be allowed to run along side what we now call the internet and not be subject to same rules as the 'open internet'.

there are lots of analysis of the massive loopholes in the various points. there are many troublesome points if you believe in net neutrality or something close to it. i'm sure you can find plenty of different articles covering various finer points if you are interested enough.

i doubt this agreement would have drawn the same ire were it not for the aforementioned belief that many people clung to that google was somehow different from other companies.</comment>


Reading List for Leaders in Uncertain Times - <AUTHOR> https://a16z.com/2020/03/20/reading-list-founders-leaders-company-builder-uncertain-times/ <comment><USER2> Really interesting article. Here's a related article on simple leadership lessons from Extreme Ownership that I had written - [https://medium.com/@brainstrained/4-nine-simple- leadership-l...](https://medium.com/@brainstrained/4-nine-simple-leadership- lessons-you-can-learn-from-navy-seals-fe2da86c80b7)</comment>


Is this the 'NEW' SEO? - <AUTHOR> http://www.noblesamurai.com/blog/seo-news/is-this-the-%E2%80%98new%E2%80%99-seo-3320/ <comment><USER2> The 'NEW' SEO is the same as the 'OLD' SEO. Build a great site, make it accessible, and promote it. Anything else is a hacky misguided attempt to game a system. If a site is built and promoted properly, there is no need for SEO 'Experts'.</comment>


SecureCanvas – interface-based protection - <AUTHOR> http://securecanvas.com/

<comment><USER2> How do you plan to deal with self-xss? It sounds like you could xss yourself and bypass any of the protections.

To me this sounds a lot like previous solutions that 'solved' security by adding hmac tokens to every link. This sounds like it would have fewer issues with AJAXey apps, but given the general prevalence of xss vs other bug classes I'm not sure its worth it unless you have a plan for dealing with self-xss besides filtering <>'"

<comment><AUTHOR> That's a very good question. Yes if you are able to inject a script it will be executed in the virtual browser and it will bypass it (not completely, you still have XHR and cannot exploit heartbleed like bugs).

First - default xss auditor by chrome will be used. It kills most reflective xss.

Second - whats wrong with filtering? It is ugly but bulletproof. Without <>" you cannot break the markup.

Third - we will be offering free antixss audit. It is routinely patched.

Main goal of this technology to prevent complex server side bugs and 0days. Interface based XSS are both rare and easy to spot.

<comment><USER2> I am surprised to hear you say that Chrome's antixss auditor is a good enough solution. I havent examined it myself, but my understanding was that there were quite a few bypasses and the chrome team isn't super interested in making it work.

I must admit it's been quite a while since I did any consulting, but rare is not how I would have described xss when talking about web apps that customers had.

Besides XSS, you're also vulnerable to HPP attacks on links. Especially with RESTful sites where you do something Directory traversal-like on links. Though I don't know how common that is going to be through form fields, rather than URL tampering, its not something I've seen anyone care about.

I guess people with legacy crap might be willing to accept the filtering, but it doesn't seem like something anyone would accept if their app had any social component.

Good luck I guess, its an interesting idea, but it seems like a very niche product due to all the usability impact it will have. Maybe there is a market for "citrix for web apps" :)

<comment><AUTHOR> > quite a few bypasses

the longer it exists the less bypasses left. it is really good at preventing simple reflective xss.

> talking about web apps that customers had.

Remark - we are talking about interface-based xss only, not all of them. It's really rare for segment this product is targeting (online banks etc).

> but it doesn't seem like something anyone would accept if their app had any > social component

the goal is to make it work for everyone out of box, including widgets and social components. and there are no unsolvable issues.

> Maybe there is a market for "citrix for web apps"

the market here is huge - everyone who cares about security the most. It prevents _all_ 0days except those that can be exploited via interface.

Absolute 0day protection. Doesn't it sound epic? Yes, securecanvas's stack itself is another layer and may have 0days but its attack surface is small.</comment></comment></comment></comment>


Voirex – Speech to Function API - <AUTHOR> https://softyak.github.io/Voirex/ <comment><AUTHOR> I have developed a dynamic and functional Javascript Voice Recognition API as a mid javascript developer. Happy Hacking! :)

<comment><AUTHOR> I will learn a lot things from your comments and will improve my project day by day :)</comment></comment>


Linus Torvalds writes C++ - <AUTHOR> https://github.com/torvalds/subsurface/commit/09ded17e1cae66e1aef95cbe5c3b86dd196c9be9 <comment><USER2> As a more nuanced interpretation: If one looks at the green lines, it's more about Linus "editing some existing cpp and h files".

If there are green lines showing Linus originating new code with "class xyz : superABC {};" ... that would be more interesting. :-)

For some more context of the diving software, there's a video presenting the rationale for migrating from Gtk to Qt:

[https://www.youtube.com/results?search_query=gtk+qt](https://www.youtube.com/results?search_query=gtk+qt)

</comment><comment><USER3> ... or was it really him? IIRC, anyone could lay claim to that email address for their PR and github would resolve that to his account.

<comment><USER4> The repo is for the divelog software he wrote himself. So I'm pretty sure that it's either him or it would get caught real fast if it wasn't.

<comment><USER5> And it is owned by github.com/torvalds</comment></comment></comment>