9 ms·
A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Micros
by c0l0 5y ago
A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there.
In the old shop, we eventually had all kinds of important subsystems hooked up to our internal IRC server: Monitoring and alerting. Source control and Wiki activity. The deployment pipeline. Ticket activity reports. All these services were pretty much effortlessly set up to provide useful, real-time status information broadcast to topic-specific channels users could idle in. Everyone could stay informed on topics of their interest, in real time, with no barrier to entry. It was really good, and the implementation completed in a few hours total, for all use-cases, due to irc's incredible simplicity.
Due to the benefits I had reaped from that setup before, I tried to implement parts of it on/for the MS Teams platform at the then-new job. Getting the Teams Python SDK to implement a bot-like entity running alone proved to be a days-long ordeal, and whatever followed wasn't much more pleasant.
In the end, we let someone set up two email-to-teams-channel-forwards which kinda worked, but suffered from obnoxious, multi-minute relay delays.
As a consequence of the tedious bringup and the latency shortcoming, the "effortless notification" initiative never really got traction.
Not only because of this particular experience I am a firm believer that software/system simplicity is a virtue that can neither be overstated in importance, nor substituted by anything else.
- alufers 5y agoI once needed to create a bot that sent notification and I just used the webhook feature in a Team channel. Not defending Teams though, it is a horrendous piece of software.
- c0l0 5y agoMaybe that wasn't possible/enabled for our particular deployment (that was in the IT dept. of a big European bank), as we had what I've been told was a strange bastardization of O365 and other MSFT services - a mix of on-prem and cloud services unlikely to be found elsewhere. At any rate, for the IRC server at the shop I was at previously, I had "webhook" support/a http(s)->irc gateway implemented on my own in much less than an hour via CGI ;)
- arbaal 5y agoIsn't your comment then very specifiy for that installation of yours? When you use MS Teams in a "normal" O365 environment, then every feature you described for IRC is possible with weebhooks and the cards API. Simple CURL based integration.
- 41b696ef1113 5y agoI will second with another anecdote at mega corporation - Teams is entirely locked down and any of the useful integration points are disabled.
- flatiron 5y agoSame with slack webhooks. I make custom software and everyone wants slack webhooks and they are pretty easy to implement and people love them.
- trixie_ 5y agoThe integrations are a neat trick, but often end up spamming a channel where people are trying to communicate. Teams seamlessly works across platforms, and mobile with video chat, files, outlook integration, and screen sharing. Maybe IRC could of been that, but it never happened.
- lambdaba 5y agoThere are nice IRC clients out there. I don't use them and I haven't used them in a group, because even in programming language communities many have moved to Discord/Slack, but I would prefer working with multiple simple tools than a monolith, different tools for different uses, and glue them together when needed (it doesn't need to be complicated, and if it is, than some additional effort is justified)
- hiptobecubic 5y agoIf you look at these communities, there is basically only one feature of Discord/Slack that they use that IRC does not easily provide and that's ephemeral/mobile. If I go offline for an hour in IRC, I lose a bunch of messages unless I've done some backflips to set up some kind of archiving/replay in a separate failure domain (e.g. znc running on gcp). With chat services, the service is essentially znc for free. The rest of the shift is explained by discord being popular for other use cases (e.g. as a twitch companion), overwhelmingly dominated by younger users. IRC isn't getting new users and over time, this means the community will migrate due to turnover. Thank god we at least have things like matrix bridges, but discord is a lost cause.
- lambdaba 5y agoI think the latter argument is 90% of the reason. Too bad this new generation doesn't have an opensource base of software to work with, or rather somehow didn't get acculturated to the existing one. Actually, that's probably because there were those few "killer features" such as offline messages that the existing systems didn't have.
- LinuxBender 5y ago
- lambdaba 5y ago100%, the fact that you can literally pipe some data in a command-line IRC client is 1000x more conducive to such tweaking than using custom APIs/SDKs long live the Unix model!
- michaelt 5y agoDoesn't that mean you get a channel join/leave for almost every message?
- lifthrasiir 5y agoIt is possible to post a message without joining if the channel has -n set (not the default for the obvious reason).
- crest 5y agoSo clients can read lines from a pipe as stdin.
- ferdowsi 5y agoI don't see why you couldn't do the same in a Slack command-line program as well? Not hard to find simple examples of that. https://github.com/csabapalfi/slackcat https://github.com/csabapalfi/slackcat
- littlecranky67 5y agoI think the op meant on the protocol level, not client. You can literally do `cat mycommands.txt > /dev/tcp/...`. IRC is pretty simple, I remember using telnet just for fun to connect (also the PING message replies are annoying to type yourself) and at one time, (ab)used an FXPable FTP server data port trickery in ASCII mode to send a message to a channel. Due to its simplicity I could see its application as a falback for global communication downtime/outages (as we had with FB/Insta recently).
- userbinator 5y ago
- Nemi 5y agoI tend to agree. I have the same reservations with HTTP2 to a lesser degree. I won’t deny that the complexity added by HTTP2 will greatly improve speeds in certain cases, and this may very well be needed to keep the greater interwebs working at comfortable speeds moving forward, but a part of me is greatly saddened by losing the sheer simplicity that is HTTP1.1.
- tomsmeding 5y agoAre we going to lose the simplicity of HTTP/1.1? I think that would only happen when we get servers that support only HTTP/2, and I hope those will be limited to hobbyist use for a while yet.
- spenczar5 5y agogRPC servers, which are increasingly common and certainly not a hobbyist thing, are http/2 only.
- littlecranky67 5y agothe problem is that HTTP2 mostly does not bring the expected advantages that connection multiplexing promised, as HTTP/1.1 connection multiplexing over multiple tcp sockets are in many cases better performance wise. Only HTTP/3 with QUIC addresses this, so I have mixed feelings about HTTP/2.
- mcfedr 5y agoI've not used teams, but both slack and Google chat make it very easy to post messages, a simple curl call has often been more than enough in lots of scripts
- lloeki 5y agoThat is, unless the enterprise has policies to abide by disallowing API calls, in which case you're stuck with the official client and vetted integrations. Same for mobile, the advantage vanishes once enterprise requires your (usually personal) phone to be surrendered to corp IT via MDM (which I sure as hell won't do). The whole value proposition of Slack and Teams for their customers is control.
- deberon 5y agoWould IRC even work in that nameless enterprise?
- singron 5y agoIRC might be run by engineering there for themselves. 3rd party chat would got through procurement and be provided by IT for the whole company, and after the last SOC2 audit, they had to lock it down.
- lloeki 5y agoTechnically, yes. In real life, no. I don't even blame such enterprises because most of the time it comes from regulations or outside policies that customers mandate, something like all enterprise data (and thus communication) has to be firmly under control of the enterprise with hard guarantees, otherwise you just don't get to work with those customers. So you get a locked down Slack/Teams, and the email+calendar system disallows any native app unless the device is MDM'd, and even that is only with first party clients such as the Gmail app or Outlook. TBH I think most companies are trying to do their best there, but they're stuck with some kafkaesque liability system.
- 5y ago
- _8j50 5y agoModern apps have modern requirements like better security. Better UX, quality and security beats dev convenience every time.
- erikbye 5y agoI find Matrix a fine substitute for IRC. Very simple to write clients and bots for. And you get modern features IRC either lack or does not do well.
- miked85 5y agoIn my experience, Teams has been a terrible alternative to most every option out there, including IRC. The entire UI/UX seems like an afterthought at best.
- peterangular 5y agoAgree - it's just Microsoft buy-in at this point. Every product from Office 365 to Teams to just Windows itself is suffering. To think people build their businesses on this is mind boggling.
- littlecranky67 5y agoI think it is unfair / nonsensical to compare Teams (or Slack or Discord) to IRC. IRC is an open protocol for creating chat networks, not a desktop client. The user expierence from IRC could differ vastly depending on which client you use (mIRC, xchat, irssi...). But it shows how in todays world we create this silos/islands of proprietary solutions that are not inter-operable.
- harikb 5y agoGP is comparing the integration experience and API layer.
- tarkin2 5y agoWith your IRC system, how did you deal with channel history, i.e. seeing messages that were delivered to the channel while the user wasn't there, something that slack and teams does well?
- Fuzzwah 5y agoI'm not the OP, but the usual method is that everyone runs an irc client in a screen on a server that they SSH into from their workstation.
- pmarreck 5y agoI did this years ago and this was indeed one way to do it (apparently still is)
- gaws 5y agoI can confirm that I use this method. It works.
- pmarreck 5y agoI have a possible thing I discovered recently that you might like (especially if the machine you leave screened is on your home LAN): https://tailscale.com/ https://tailscale.com/ has a free tier that lets you pretty trivially set up a VPN (with separate DNS and everything) from anywhere, to anywhere (and the name resolves correctly from anywhere as well). Avoids having to map ports etc. Anyway I've been playing with it and it's a neat toy at least, for sure, being able to access anything in my network from anywhere without having to manage port-mapping at my router, etc. I'm actually going to use it to set up my own cloud dev I can access from anywhere, but it has tremendous utility beyond that
- c0l0 5y agoWe had an internal instance of ZNC for human users to connect their clients to (at their option - but that was the documented and preferred way of getting onto the IRC network). Creating ZNC user profiles was part of the semi-automated onboarding/setup procedure, whilst ZNC authentication was done against the dovecot IMAP/SASL server we had for email. More casual IRC users in the company (marketing etc.) usually preferred to use an intranet-hosted web application (The Lounge) to access it from their browser, while most IT people had native clients of their choice set up (hexchat, irssi, etc.). Worked well.