Hacker News Reader

Comment by dandelany | Hacker News Reader

You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially displayed element. The only thing it may not handle well is file uploads... but even then, I seem to recall IRC having built-in support for sending files?

View on HN

> is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps

The IRC protocol is old. It predates HTTP. Some things are possible in theory, but pointless if no client supports them.

Look into ircv3 (http://ircv3.net/), they're writing new specs for the IRC protocol to build exactly what you're talking about. It's very promising, although IMHO too little, too late - Matrix looks like it's going to take the crown eventually.

I'm sure that I'm over simplifying, but can't you just put tokens or markdown right in the chat for those sort of things?

If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?

No amount of markdown makes up for the lack of offline messages.

Offline messages is a server issue, though - in principle there's no reason why you couldn't have a server that remembers offline messages and passes them to the client when it reconnects, framing them as regular IRC messages.

There is, actually. IRC has no concept of timestamps. IRC has no concept of foreign metadata, even, so shoehorning isn't even possible without looking horrible.

IRCv3 fixes all that.

Prefixing a date/timestamp unless the client has asked for IRCv3 timestamps is reasonable.

And now, you just broke essentially all clients that already support channel logs by duplicating anything they already had.

This is a problem bouncers are already solving best they can, and it still sucks. It's not good enough to compete with slack.

Channel logs is a marginal, client issue, not a protocol issue. Does anyone do client-side logging on any of these other services that do server-side message history?

I didn't say anything about competing with slack.

Yep. This is how slack does it, least for their xmpp gateway. I imagine that their irc gateway is similar.

ZNC handles this nicely.

The tech is all there. It just sucks to set it up yourself and should just work out of the box.

That is 100% true. But I use IRC and have offline messages. It's IRC, so I had to cobble something together to make it happen, and the UI is ass, but... I have that within the IRC protocol.

We already have offline messages, it's called email.

"Oh, Johnson isn't online? better send him an email. /message acmebot email johnson@acme-supply.co Get your ass to mars!" chat bot sees the command and sends him the email.

Sorry if I'm coming off as cynical it's just that I see a trend of the entire community trying to fix problems that aren't real problems.

Chat is not e-mail. It's chat. It has a much different feel to it. One brings a different mental context to e-mail than they do to chat. It is accessed differently, and the use patterns are very different. Hence, solving "offline chat" by sending an e-mail... this is not a real solution.

You could argue that some of the characteristics we find in chat are not useful, counter productive, etc. And there is probably some truth to that. But that is a different argument than what you made.

Your "solution" does not work well with people on mobile. People on 2G/3G/LTE can alternate rapidly between online and offline. This kind of problem is easily solved by the chat server behaving like a store-and-forward device. Which is exactly what email is. But nobody likes to converse entirely using emails.

Chats have an important place because they allow us to say small things, quickly. What you suggest will result in no viable chat for mobiles, only emails. We can probably make a chat app that looks and feels like whatsapp but actually sends an email for every message. Dunno what problems this might have.

That's not really a protocol level solution. Sure, it works, if you know how to do it - but you don't automatically gain that knowledge "out of the box", you have to learn it. It is a real problem to anyone trying it out that doesn't understand why they can't send a message to someone who is offline.

Also mobile notifications - that's a huge benefit of Slack and an IRC app couldn't (as far as I can see) provide them without maintaining a constant connection.

These services are really replacements for IRC bouncers, which are not as well standardized (but should be).

It has DCC protocol built in, but it isn't nearly as robust as most would like for it to be.

Reply on news.ycombinator.com