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.
https://plus.google.com/u/0/+JeromeLeclanche/posts/icC6gDToB...
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/) 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...).
No competent person setting out to design a group communications protocol in 2015 could honestly say they'd use IRC as a starting point.
The rest of what you've said is pretty much true.
I haven't seen unicode messages on IRC channels, but I don't spend much time on IRC anymore, and so this is interesting new information for me --- but there's more to being 8-bit clean than simply supporting internationalized character sets.
This is not possible on a technical level, having nothing to do with IRC itself, but instead written into the encoding design of UTF8.
First of all "7 bit" physical communication never really existed in the age of TCP - the protocol has always moved 8 bits at a time around. The "7 bit" era refers to nobody actually agreeing what codepoints within x80 ~ xFF actually mean. This is even partially true today - not everything has agreed on speaking UTF8 (hi Win32 APIs).
On the actual point of why neither 0x0D nor 0x0A will ever "manage to collide".
In a single-byte encoding (called codepages, https://en.wikipedia.org/wiki/Code_page#Noteworthy_code_page...) 0x0D always means just that, as pretty much all ASCII-derived codepages do... well, respect ASCII ( note - this does not touch on the horror of EBCDIC, which is alive and well today (2015) too ).
In the case of UTF8 any continuation byte can only carry values in the range of \x80 ~ \xBF, and any leading byte can carry values in the range \xC0 ~ \xF7. So no matter how you slice and dice things, the resulting UTF8 will have every ASCII character meaning itself (this includex \x0D and \x0A ), and the only ambiguity when mistakenly treated as any single-byte encoding would be in the "what do we do with the upper 7bit range" part ( \x80 ~ \xFF ). More info here: https://en.wikipedia.org/wiki/UTF-8#Description
True, other multibyte encodings are not so convenient: for example \N{MALAYALAM LETTER UU} ( http://graphemica.com/%E0%B4%8A ) looks really bad CRLF-wise in both UTF16/UCS2 an UTF32.
But this is why UTF8 "won" for all intents and purposes. And this is also why "escaping" is not necessary under virtually any modern environment, so IRC lacking any such mechanism is not really relevant.
( No opinion worth sharing on the rest of the article/discussion ;)
They need help, go check them out.
http://www.matrix.org/
https://github.com/zulip/zulip
https://wiki.tox.chat/users/faq#what_is_tox
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 ]
* IRC (https://github.com/matrix-org/matrix-appservice-irc)
* Slack (https://github.com/matrix-org/matrix-appservice-slack)
* Verto (https://github.com/matrix-org/matrix-appservice-verto) (for talking VoIP with FreeSWITCHes)
* 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...) (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. 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]
Every time it loses another user to a proprietary platform, it loses another battle. Is that what "battle-tested" means?
A lot of the other deficiencies are a consequence of any decentralized, open resource, due to "tragedy of the commons" effects. Those will always require active admin participation to resolve.
If you're running your own irc server, you'll probably never notice anything. If you do, it's as simple as adding a server password (or maybe even changing the default port among some other settings), and anything unwanted will likely be a thing of the past (assuming you don't have dedicated people attacking you).
On your comment about IRC bots and services, networks don't see that as something that is up to them. If something requires a U:line or other network privileges, then it's up to the network staff to implement that, sure, but anything else is for their users to do. If IRC networks were for-profit, maybe you could expect them to have things like this and advertise how amazing all of their features are to potential clients. But IRC is nothing but a money sink for everyone involved, and there's therefore often little incentive for networks to implement and integrate a lot of bots and functionality that aren't integral to network operation.
Apart from this, spam is a really hard problem if there are resourceful people dedicated to it. Email has existed for even longer than IRC, and despite absurd amounts of work into anti-spam systems and functionality with it, it's not too surprising when spam manages to finds its way into your mailbox.
I still agree there's a lot of room for improvement, both at the protocol level and at the user level, though.
is there a way for me to, instead of using a server password, use something like OAuth so that I can grant access to the server based on my companies central login database? otherwise, every time someone leaves the project, we have to rotate the server password...
Well said, I chuckled. Let me just add something...
If you want a paper trail of anything, use an email you own.
I have a friend who was locked out of a startup's Slack right before he was due to be paid for three months of work. He had been discussing business inside of Slack, and instantly lost access to all of those messages.
Could this have happened if the startup used a private email server, or a private IRC server? Of course. But if they were using more open protocols, he would have at least been able to back up the messages. Slack provides an easy tool for backups to admins, but not for normal team members. Slack provides an API for all users, but team admins can disable the API. Slack also allows team members to connect over IRC and XMPP, if team admins turn on that feature (https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...).
Slack is great, I love using it. Just remember who owns the data. Always use your own personal email if you want to create a papertrail, as my friend found out.
I think your argument is somewhat null....
So don't use AWS or Google App Engine or Heroku? etc. Why?
I use Facebook for a lot of my communications. Seems to be working out OK so far.
Use the tools that help you get your work done efficiently. Consider the long-term consequences, of course, but if someone took all of my Slack team messages and told me I couldn't have them back, I'd be annoyed but it wouldn't affect my productivity much.
OTOH, losing the ability to coordinate via Slack, as you're suggesting, would certainly lower my productivity.
Leaving aside that there are extremely valid reasons not to use those services, communication is a huge deal. Can you imagine if email was a walled garden?
http://www.tricksofthetrades.net/2015/09/10/slack-irssi-conn...
I feel like that has to diminish the walled-garden, proprietary weight at least a little bit if slack & irssi can communicate. And it works over SSL too. Once I started doing that, I didn't mind using slack. You have to "/ignore" certain server messages though or your whole screen will be spammed with them and you'll barely see the stuff people are saying.
https://slack.zendesk.com/hc/en-us/articles/201727913-Connec...
Amen to that. Our company yet to transition away from using Salesforce, but we greatly restrict its use for the reasons above, and one day will move completely away from it.
Completely different situations. Neither of your examples could sanely be described as shady or underhanded - neither of them gave the producer a business advantage it wouldn't otherwise have. FOSS developers don't owe anything to you - they don't have to continue to develop your favourite feature for the rest of their lives. They do however give you the freedom to do that yourself.
For everything else, including at work, I/we use privately hosted solutions like GitLab, where we control our own data.
If you have a single person that is even slightly technical, it should be trivial to set up your own IRC server, and then you get complete control over all of your own information.
Even with that, you still can choose from a multitude of servers, services, clients, bots, client scripts, bouncers, and so on. Anything common you want to add on after that point has likely already been written for what your purposes (and is of course open-source), whether it's a git commit bot, a logging/relay bot, or even end-to-end encryption (even after TLS). It's even quick to write custom IRC bots for arbitrary purposes if you use a framework or copy some example code (even without that, it is only so bad).
That's a pretty narrow view of 'slightly technical'.
These days, we've got generations of people who can manage their own email account setup, install web apps and mysql databases, configure zapier to connect multiple apps together within a few minutes. I know dozens of people who do things like this all day long for their clients.
I'd call all these people more than "slightly technical", but there's no way on earth they'd be qualified to set up and administer an IRC server.
You need far more than "slightly technical". "Slightly technical" sets you up for disaster. And... it's not 'trivial' to understand what's going on and how to manage it.
I agree, though, it should be trivial. It's just not.
Technology isn't easy. Pretending it should be causes problems.
The article does not even discuss the fact that projects that opened a slack community with a big increase in their audience. Apparently audience is much less important than purity.
I want to spend my time working on React, not be a sysadmin for the irc bot. I switched to botbot.me and it's been always up and with a much better interface :)
I'm "slightly" technical and I have absolutely no interest in setting up an IRC server for my project or company. That's time better spent on developing our offerings. While I have no doubt I could set up a server, I also have no doubt that setting it up and maintaining it would drain time unnecessarily.
It's the same reason that I don't advocate for most people to maintain their own servers in 2015.
I really don't get this, 99% of the stuff you use everyday is closed-source and proprietary. Most often the tradeoff in something bad happening (which has yet to be with Slack) versus having a functional and productive system is more than worth it.
Or do you also build your own computer from raw silicon and communicate with pirated radio signals?
This is Hacker News; I expect the average to be around 20%
If some basic programming chat about an open source project isn't safe then we should all throw away our phones and turn off the internet immediately, but I don't see that happening. This is basically bikeshedding on how to run open source projects.