> Teams who can’t use SaaS rely on cryptic, decades-old technologies. As an example, the US Army uses myIRC to order missile strikes
"myIRC" doesn't exist. The name of the protocol is IRC. The name of a popular Windows client is mIRC. WikiLeaks called their leak "mIRC logs," which is where this trope came from.
The United States military (not just the Army) uses Internet Relay Chat for a whole lot of C2. It runs on a network, both IRC and IP, dedicated to the purpose. Given how long IRC has been in existence, that they've been doing it since the early 90s, that the use case is the perfect ideal for IRC, and that the average modern Web app is less reliable than my last Datsun, I have a hard time finding incredulity at sticking with something that works.
Even beyond that, IRC is text-based. It is not cryptic. An IRC client is a common first software project. About twenty lines of Go gets you a bot. You can make IRC look exactly like Mattermost with a week of hacking in your favorite framework of choice, and then you're not reinventing fanout. Entire products have been built atop IRC.
Even beyond that, guess how many protocols are decades old in just the software development workflow for this product. Pretty tired of "that's old, let's do it better," even though I hate finding myself on this side of defending IRC.
IRC federates easily, requires minimal resources, and is vastly more efficient when it comes to bandwidth usage. (you'll notice this over satellite links)
There already are a number of IRC client web frontends. The one I'm working on is Glowing Bear -- https://github.com/glowing-bear/glowing-bear . It uses a proper IRC client running on a server (WeeChat in a terminal multiplexer) and connects to that via WebSockets. Minimal reinvention of the wheel, and you can continue using all those nice scripts, triggers, and filters that WeeChat offers. The frontend (Glowing Bear) is completely static and runs 100% in your browser, connecting to your server directly.
I really don't get those projects that consist of a designer frontend and a terrible half-baked IRC client in nodejs.
Designer front ends matter. You have no screenshots, which is going to severely limit adoption. If the design is average or subpar, it will limit adoption.
Also, integrations with third party services matter. Everyone seems to ignore this, but it's critical.
Uhm, there is a screenshot in the README, both for mobile and a desktop browser. Maybe we could move it up a bit more. As for the design, sure, you're right that it matters. We try to keep it as clean and intuitive as possible, but none of the core devs is a designer, so we just do it as best as we can. Ideas for improvement (or even pull requests) are always greatly appreciated!
For third party services, Glowing Bear has a number of plugins that embed various content right in the conversation (images, youtube, spotify, etc). Not sure if that's what you're referring to.
The uhm is unnecessary; I don't see any screenshots on the GitHub page, linked or otherwise. The page linked from the website is https://github.com/mattermost/platform.
For third-party services, I'm talking about things that matter for getting work done. For example, issue trackers like JIRA.
The IRC protocol isn't pretty, and there are plenty of incompatible server implementations, but if you're controlling both the server end and the client end it's certainly where I'd start. My first thought when I saw Slack was "someone did a pretty web irc client finally, cool" (I have no idea if they use irc internally? but it seemed such a direct match)
The IRC protocol might not be pretty, but what protocol is? HTTP? AMQP? XMPP? Protocols are not meant to be pretty, just efficient and robust enough to support the desired feature set. It's a shame that none of Slack, Hipchat, now Mattermost support IRC. They're all just IRC clones, drawing on the same ideas, just giving you a crappy (but pretty!) web interface.
Slack "supports" IRC in that you can allow IRC connections, and then people can connect to your Slack instance via IRC. This might also be the case for some of the alternatives.
And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors. The IRC people do not get the same graphical elements as everybody else. They can't use custom /-commands.
In conclusion, in order to communicate the most effectively, you have to know who's on IRC and think about the differences in user experience for these people versus everybody else.
IRC has weaknesses (namely lack of centralized logging and unspecified text encoding) and fixing these weaknesses means forgoing support for existing IRC clients.
> And it's a pain in the neck! It means that some of the participants in the channel are not able to read what's happened while they were away. Some of them get encoding errors.
Everyone I've ever worked with who uses IRC has a client or bouncer running somewhere that never disconnects and assumes UTF-8, so neither of these are realistic problems.
I also assumed Mattermost supported IRC, without even checking. It's a bit disappointing that it doesn't, but I wonder how easy it'd be to add support for IRC in Mattermost, given that we have the source code?
Whilst I take your point, worth noting that Slack does offer an IRC gateway to allow for use via an IRC client. Not quite the same thing as basing everything on IRC, but better than nothing?
I saw the IRC gateway feature a little bit after the launch. I don't remember seeing it in the initial launch feature list and that it was "coming up" more or less.
Yes, but Slack is slick, plaid, and even gorgeous.
Seriously, these days it seems most software like this is judged purely on its external styling and aesthetic beauty. You're right, Slack has no new features over IRC or any other decent chat clients in the past. But read any article that praises slack and if the slick UI (or whatever adjective is in style these days) isn't mentioned up front and center, I'd be surprised.
Of course the UI's 'slickness' and 'modernity' would be top discussion points for people writing such articles as they're usually not technical enough to argue the merits of tabs vs. spaces or braces vs. non-braces which the creators of such software usually argue about to the detriment of real issues.
Can you recommend your favorite protocol OR app for a small dev company where we share files and want to keep a centralized area where team members can chat, using various apps (or web interfaces)? The more robust the better, doesnt have to look amazing!
"myIRC" doesn't exist. The name of the protocol is IRC. The name of a popular Windows client is mIRC. WikiLeaks called their leak "mIRC logs," which is where this trope came from.
The United States military (not just the Army) uses Internet Relay Chat for a whole lot of C2. It runs on a network, both IRC and IP, dedicated to the purpose. Given how long IRC has been in existence, that they've been doing it since the early 90s, that the use case is the perfect ideal for IRC, and that the average modern Web app is less reliable than my last Datsun, I have a hard time finding incredulity at sticking with something that works.
Even beyond that, IRC is text-based. It is not cryptic. An IRC client is a common first software project. About twenty lines of Go gets you a bot. You can make IRC look exactly like Mattermost with a week of hacking in your favorite framework of choice, and then you're not reinventing fanout. Entire products have been built atop IRC.
Even beyond that, guess how many protocols are decades old in just the software development workflow for this product. Pretty tired of "that's old, let's do it better," even though I hate finding myself on this side of defending IRC.