Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.
Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.
A channel stays a channel until nobody's in it. It's trivial to make a bot that sits in a channel and logs it. And it's trivial to hook up a search engine to that bot.
> Other important missing features are ease of use in terms of creation of topic-focused channels, private channels, and high quality mobile and desktop clients.
Like on freenode #reprap , #3dscanning , and thousands of other topic based channels?
And setting private bit is easy as a channel operator to limit who shows up.
And with completely public and open protocols, anyone can make an awesome IRC client. I have one already on my phone.
And there's also bots that can store and send files via http or ftp. I could also make one that saves/retrieves via Box, Dropbox, or any other storage medium trivially. Node-red makes that easy.
I have actually done that, and I know it's not trivial.
Few want to spend time tinkering with bots and hooking together archiving services. They want a nice Slack-type experience.
Come to https://webchat.freenode.net/ room #hntesting
I'm kefka, and my bot is hn_kefka_bot talk and PM, and then check the Dropbox log.
Here you go. http://webchat.freenode.net room #hntesting
Files end up on Dropbox here: https://www.dropbox.com/s/ukffgmwntypfg4m/ircchatlog.txt?dl=...
Searching wouldn't be too difficult. That's just loading the data up in a Hadoop and then regurgitating it. The only 'doop cluster I have now is a semi-production one. Working on getting a 150 node set up at the hackerspace.
__________________________
Edit: Added time date stamps, and indication/handling for private messages to the bot.
Privs now allow me to extend the functionality of the bot to do all sorts of things, like upload to MongoDB, email all logs, kick users, save to BOX, or manipulate the neopixel strip in my room.
No matter how much you push and say that everything Slack offers is doable in IRC, doesn't change the fact that you still have to go through the troubles of setting that stuff up.
While I agree that setting up a bot isn't hard, I've done it for the IRC channel I created and still sit in daily, but fact of the matter is Slack is a matter of signing up and enabling a couple of features.
My job for my company is to build our product, not an internal chat tool. That's what Slack is for.
Where is a Slack that can do "sensitivity calculation" to alert users of possibly hostile tone? That's right. Not created yet. Give me a half hour and I could have the beginning of that. I also could get translation facilities built in so that English/French/German/Spanish could be seamlessly translatable.
The sky's the limit. And your negativity diminishes your ideas.
If that's your thing, that's your thing and go do it. But it's not a lot of peoples, and that's why Slack is so popular.
But that's not what I'm doing.
Company A does really good semantic analysis. Company B does chat, say Slack. Company C file storage. Company D does search.
Now, I'm spinning up or using a current server. In this case, lets do IRC to Company Chat, B (bidi bridge). I connect to Company B with my user, and a user on IRC. Logging is turned on and saved, to Company C.
Whenever messages are sent, they are run through API from company A, checking semantics and feel. Score applied personally to help devs be more humane.
While all this is happening, search D is going through files presented and making a searchable DB of date/time, channel, user, and text.
And, I just created a new product.
That's exactly the point. Is this what your day job is paying you to do?
Someone set up Slack for the company. The same person could have set up an internal IRC server.
I'm also one of the leads for IoT rollout. In essence, I look at many sectors and areas at the same time, and determine how it can be used in our org.
I was looking at message passing using IRC as a form of command and control. The hackers have used it successfully for controlling a force of DDoS clients; why not a server farm? I know that Ansible, chef, and others exist. But IRC is human readable, meaning status messages can be passively read.
Pretty much, I have a dream job. I can get funding for pretty much anything I want, have access to petabyte FS, access to 3 supers(HPC, not clusters), multiple clusters, and more. And then I'm asked, "what can you make with that?"
You learn quick in those situations.
It's a fools errand to extend a private platform like Slack. They're already adding IRC features to their system, along with running a modified IRC bouncer.
Why play catch-up or copy-target when I can just use IRC directly?
Hell, I could do what they're doing for $1/user/month just by hooking a RADIUS server up to my nickserv. Easy peasy.
eh... slack has consistently said that large communities shouldn't use its services. - http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...
Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem, and there is quite a few high quality mobile and desktop clients for IRC.
That has nothing to do with Slack-like apps, and everything to do with Slack.
> Go talk to the hundreds of FOSS communities that use IRC. they have all fixed the persistence / search problem
I am part of many FOSS communities on IRC. None of them have "fixed" that problem. There might be one or two that archive the channel somewhere. That is no substitute for real in-app persistence and search.
There is a reason slack has a problem with that - scaling is hard.
There is also the advantage of not having silos - if I have a problem with a dependant library I can "/j #libname" and ask a question, instead of searching for what slack, or slack like tool they use, signing up, installing whatever app is needed to access it, and asking the question (and remembering what app they used, so I can keep it open for issues that run over a few days.)
Detachable screen sessions make up somewhat for it, but they're still pretty limited (you might have /joined the channel only later), and it requires a personal service running, that must be attended to & etc.
Apart from the tech problems with 1000+ sized teams, it's insane even considering the free tier with a 10'000 message limitation for 8000+ users.
So the team size isn't itself the problem; instead, it's the idea of wanting 8000 active subscribers in the same single channel that doesn't scale. Doesn't work on Slack; doesn't work on IRC, either.
At the scale of 8000 "viewers", you need the sort of specialized "presentation" software used for managing MOOC lectures and corporate shareholder calls, with fan-out servers, voting indicators, and the ability to "raise your hand" to ask the presiding officer to grant you a temporary +v.
A well-tended IRC server has those via bots.
Other important missing features are ease of use in terms of creation of
> topic-focused channels
wut? This is totally easy in IRC: /join #topic-channel makes the channel
> private channels
I'm tempted to say that a bot can provide that... but sure.
> and high quality mobile and desktop clients.
Not buying that, sorry, I've been happy with my mobile/desktop clients; they are relatively full-featured.
[1] http://colloquy.info [2] http://colloquy.mobi/bouncers.html
At very least for the persistence part, there is a proposal to add CHATHISTORY batch type[1] to IRCv3 which should allow the server to replay chat history on join (or on request). Search is something else that probably need a little bit more work (especially for a server-side search), though.