[Karunamon]

I wish the IRC meme would die in the enterprise world. It's an evolutionary dead end that ignores the last 20 years or so of improvements and expectations for a messaging system.

* Service packages are poor replacements for fine-grained permission controls and registration.

* Always-connected clients are poor replacements for message history and push notifications.

* DCC is a a poor replacement for video chat, screen sharing, or file sharing.

* /whois and /away are poor replacements for user status tracking.

IRC had nearly 30 years to evolve and has not. It's time to move on.

[kuschku]

> * /whois and /away are poor replacements for user status tracking.

That’s why IRC has away-notify, which does exactly what slack and co do for status tracking.

> * DCC is a a poor replacement for video chat, screen sharing, or file sharing.

That’s why people are working on an RFC for WebRTC negotiated via IRC.

> * Always-connected clients are poor replacements for message history and push notifications.

That’s why message history and push notification RFCs are being worked on, and already implemented in some IRCds (Snoonet transmits the last 5 minutes before login marked as such, for example, others transmit everything you request)

> * Service packages are poor replacements for fine-grained permission controls and registration.

That’s something that I hate, too, but some modern IRCds have far better permissions systems nowadays. Oh, and registration and login happens via a standardized SASL anyway, so you can also auth via OAUTH if you have to.

[Karunamon]

I notice a lot of "being worked on" in your reply, which really exemplifies the problem. Being worked on might have been okay a decade or two ago, but it's really too little, too late when there's stuff out right now that provides everything IRC does, but better. The mindshare is gone, the user goodwill is gone.

A reference implementation of a WIP RFC is rather different from a thing you can download and install and have working right now in a server that isn't likely to change their implementation in a way that makes those features unusable (since they're headline features being sold to enterprises).

There's also the fact that most IRC clients suck, with interfaces that look and control like xterm circa 1980. Fine for the people that read Hacker News, offputting for everyone else.

Do any of these RFCs or newer IRCd's support full message auditing for the legal folks?

SASL is nice, but unless you're into something like Okta or some other homegrown thing, most are going to use plain old LDAP/AD. And AFAIK, permissions on most IRCd's are still pretty spartan. There's no way to make a room visible to one class of users but not others, as there's either visible to all or invisible to all.

[kuschku]

> There's also the fact that most IRC clients suck, with interfaces that look and control like xterm circa 1980. Fine for the people that read Hacker News, offputting for everyone else.

This is konversation in 2017: https://blogs.kde.org/2017/09/05/konversation-2x-2018-new-us...

The version of Quasseldroid I am working on right now: http://i.imgur.com/obsJDyg.png

Textual, a macOS IRC client: https://www.codeux.com/textual/public/images/v600media/Yosem...

> A reference implementation of a WIP RFC is rather different from a thing you can download and install and have working right now in a server that isn't likely to change their implementation in a way that makes those features unusable (since they're headline features being sold to enterprises).

That’s why the IRCv3 Working Group isn’t some people in an ivory tower, but actually the implementers – the developers of the largest IRCd implementations, and of all major clients cooperate to design and ship new functionality. This means that basically every client and server has an implementation by the time it ships.

> SASL is nice, but unless you're into something like Okta or some other homegrown thing, most are going to use plain old LDAP/AD

The guys at CoreOS have a simple single-click deployed system for bridging LDAP/AD for that purpose. Alternatively, RedHat also has a solution for that, and provides enterprise support for their product (Keycloak), too.