3 ms·

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.

petercooper 12y ago
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?)
- tracker1 12y ago
  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.
  - nvk 12y ago
    I don't personally use it, but this might help your https://hubot.github.com/ https://hubot.github.com/
    - asenchi 12y ago
      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.
      - koide 12y ago
        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)
- yebyen 12y ago
  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.
  - koide 12y ago
    See above, I use jabber for chat (supports backlog) with ejabberd and for other automation tasks I use hubot which integrates nicely with XMPP.
Xylakant 12y ago
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.
ianstallings 12y ago
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.
acdha 12y ago
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.

petercooper 12y ago

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?)

tracker1 12y ago
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.
- nvk 12y ago
  I don't personally use it, but this might help your https://hubot.github.com/ https://hubot.github.com/
  - asenchi 12y ago
    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.
    - koide 12y ago
      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)
yebyen 12y ago
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.
- koide 12y ago
  See above, I use jabber for chat (supports backlog) with ejabberd and for other automation tasks I use hubot which integrates nicely with XMPP.

Xylakant 12y ago

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.

ianstallings 12y ago

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.

acdha 12y ago

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.