Host your own IRC if you care about the privacy and security of your communication.
There is no reason why you can't take 10min to setup a IRC with SSL on your own.
Yes, Slack is awesome, lots of features, but it's not yours!
back
8 comments
> There is no reason why you can't take 10min to setup a IRC with SSL on your own
For the VAST majority of people this would not take just 10 min. Not only would I first need to research the different IRC servers out there but I'd have to get a server to install it on (which is not the fastest processes where I work). Then I need to get an SSL cert (which is like pulling teeth here) unless I want to use self-signed and listen to everyone bitch about dealing with that (and some aren't tech people and I've have to walk them through that). Then I need to find clients for everyone (Windows/Mac/Linux) also now chat is only accessible from inside the company unless I want to expose it publicly then I need to worry about security.....
OR I could pay $X/mo and have it up and running in seconds... Slack is not the end-all-be-all but I quite like it and use it with friends as well as public slacks. IRC is great but let's not pretend it takes seconds to set up everything you need...
And then you have you setup something like ZNC so people can catch up to history while offline.
Thanks for the ZNC ref.
It will take you more than 10 minutes to just choose the ircd to use. Not to mention configuration and maintenance.
I looked through the ircds available in Debian repositories the other day and they didn't look very fresh. So you might also have to package them from source and make sure that stays up to date.
Hosting your own services has some appealing security qualities (like being able to put them in your VPN) but it's far from a panacea and definitely harder than signing up for Slack/Gmail/GitHub.
Saved you the search; ngircd
I was looking at InspIRCd and UnrealIRCd which seem to be popular among smaller IRC networks. Any reason for that? Are they better suited for public networks?
The popularity of InspIRCd mostly comes from its modularity and out-of-the-box modules [1]. If you're looking for an ircd to replace Slack in terms of feature-parity, InspIRCd would probably give you the best start.
I used ircu until a few years ago, but these days it has mostly rot (maintenance, git/release tarballs code not matching, ...), and InspIRCd is pretty great if you need the customization.
Seconding ngircd
Hassle-free configuration
Agree with you in one sense of being responsible for your own security, but by this logic I should keep all my money under the mattress instead of the bank, no?
> but by this logic I should keep all my money under the mattress instead of the bank, no?
More like "by this logic I should keep all my money under the mattress instead of in a jar in my cousin's pantry, no?"
Slack isn't a secure vault for data, it's a communications tool. They obviously have some amount of security but that's not their purpose, whereas a bank is intended to store money.
I think running your own IRC is a perfectly acceptable solution if you value your data.
Not the same thing. Banks are insured against robbery and theft, so if something like that happens, customers don't lose their money. In addition, there's an insane amount of fraud protection in the banking industry, and billions of dollars of vested interests to make sure criminals are caught and prosecuted.
Can you say the same about cloud services?
Good point. Even in the worst case scenario, banks can fail and get bailed out by the public. But once information leaks, there's no "bail out" remedy possible... you can't really put the "information" genie back in the bottle.
I know you're being facetious, but the answer is possibly yes, depending on your threat model.
If you have great physical security at your home and don't trust the banks (e.g. their fee schedules), it might be a safer decision.
For most people, it's not.
Or if you experimented an economic measure that froze your account like this one [1].
They froze all accounts and they even threatened the population with opening the safe deposit boxes.
Yes we do, keep millions for our customers too; Bitcoin company here. :)
Ah, in your case, only because your customers aren't smart enough to keep theirs under their own mattresses.
In our case customers don't need to trust us, they can generate their own keys offline.
Big fan of customers having a way out and not have to trust the service provider.
This goes for any sort of SaaSS:
https://www.gnu.org/philosophy/who-does-that-server-really-s...
I don't agree with "10m"; I've hosted my own IRC server for many years, and there is configuration involved, especially if you're focused on maintaining a solid, secure system. But I haven't had to touch it since.
This is a persistent pain point for me. I don't just need owned chat, I need chat that does multi-presence cleanly and supports push notifications to mobile devices. My team is distributed and works inconsistent hours and we rely on notifications to coordinate effort when needed.
I've run internal IRC and XMPP servers before, and they do one client admirably, but multiple presences for the same user rapidly becomes problematic.
> security of your communication
Unless one is a security expert I highly doubt that a home-grown IRC system will be more secure than a professionally-run operation, other than simply being more obscure and not on a hacker's radar.
With this logic, don't use any SaaS service then.
Not sure why this is being downvoted. Setting up IRC on a .onion isn't even difficult. Setting it up with SSL is only a touch harder.
It's presumably being downvoted because it's just lazy propaganda, not a serious answer.
It'd take more than 10 minutes simply to setup a server which ircd would run.
Then, of course, you'd need the time to setup all of the other services which Slack provides (i.e. durable file storage, integration with your applications and other services, etc.) and pick or develop clients for all of the platforms people use.
Then you have to actually support all of this: that's basic stuff like redundant servers and backups, account management, and the ostensible purpose for doing all of this: staffing your own security team at or better than Slack's level.
None of that can't be done and if you already have a good ops team it might even be worth doing. It's just way more than a 10 minute job even if you cut a bunch of corners.
SSL does not protect against a variety of attacks, among them:
* breach via a compromised (guessed) password * breach via a security issue in the service and/or the host
Hosting your own service may make sense depending on your knowledge and/or threat model, but it's not a silver bullet that solves all issues. Hosting on a .onion address buys you exactly nothing in terms of security - and in the case of a company/team chat server probably not even in terms of privacy.
Setting up an ircd is not a bad idea. Then we just need to find the ircd and client that does what Slack does. (Which is totally possible, but I'm not sure it exists?)
I am interested first in persistent backlogs -- do you know an IRCd that does that? I am sure it couldn't be implemented client-side.
I remember "SILC" which is not IRC, but if I remember correctly it had this. Mainly when you join a room, you should not get tabula rasa. You enter into some context, and if the last message was posted 4 days ago, your context starts 4 days ago, and the datestamps all reflect this.
There are other features of Slack that make it worth using, but this is the one thing I don't know if IRC can support at all, that I see every other serious chat system doing.
See above, I use jabber for chat (supports backlog) with ejabberd and for other automation tasks I use hubot which integrates nicely with XMPP.
Slack also has webhooks/bots that interact with other services for notifications... pingdom, github, etc... which can be done with bots, but it gets more complicated. Not to mention search archives, file upload preservation and other display niceties.
I don't personally use it, but this might help your https://hubot.github.com/
Careful, that has basically zero in the way of authorization/authentication. Putting business logic in there on a standard deploy is asking for trouble, especially if malicious accounts have access.
I use ejabberd as chat server and as interface to hubot. Solves both authentication and backlog issues. With a ssh tunnel (or your choice of vpn), it also solves out of network access. Jabber and ssh clients exist for Android (and iOS I presume)
I know that sounds secure, but it's no more secure than just an irc server anywhere out here.
But the funny thing about all of this is there are already voice comms and chat comms clients out here in spades. The game industry created them. No need to go to IRC. Just use a more modern comms setup. I have a private mumble server myself.