Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Absence of certain features in IRC considered a feature

drewdevault.com

Post reply on HN
Print view View original

41–50 of 222 posts

Re: Absence of certain features in IRC considered a feature

#41

Post by maeln »

I love the simplicity of IRC, I still use it to this day, but I have to say, I understand why IRC cannot be used for any serious team communication.

The two biggest pain point that I see is: 1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots).

2. No offline history: You have to have a client/bouncer running 24/24 if you want history.

One thing though, because of how IRC work, you don't have the problem that other protocol like XMPP faced with multy-device sync (there is a extension for that in XMPP but, like almost every extension in XMPP, not many client support it).

Also, nowadays we should consider end-to-end encryption standard.

I feel like IRC is in the same space as email: It's a very good technology that just lack a few feature to be perfect but any project that try to replace them just end up over-bloated with features ...

Re: Absence of certain features in IRC considered a feature

#42

Post by zimbatm »

The article doesn't talk about the best feature of Slack: a consistent message history for all the users. In IRC messages can easily get lost due to network splits or client disappearing. Not having everyone with the same message timeline can make some conversations quite awkward.

This is really the only feature I miss in IRC.

Re: Absence of certain features in IRC considered a feature

#43

Post by ygra »

Athas wrote: post #23
slezyr wrote: post #19

> IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages shall not exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. Yeah, lets just forget how painful it was for non english speaking users to use IRC. 255 characters for unicode and…

I remember when this was a significant problem but with the rise of UTF-8 it is less so (even if that is strictly against the letter of the spec, it works fine in practice). Are there languages where the 510 bytes per message are a significant limitation?

Isn't a major problem that the client cannot know how long the message can be because it's prefixed on the server side again (which counts into the 510 bytes).

But apart from that, I've certainly had my share of truncated messages, both in German and English. Sometimes you want to express a thought in full in several sentences without twenty other channel messages appearing in between the sentences while you're typing.

Re: Absence of certain features in IRC considered a feature

#44

Post by Spivak »

johannes1234321 wrote: post #22
Spivak wrote: post #9

Earlier quoted context omitted.

I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad. I've been using wee-slack for a while now and I have very few complaints. I mean it's not IRC where the protocol is etched on stone tablets but Slack has been thus far a good steward of their API.

The difference is that the IRC standard is decades old and stable and made for "independent" clients. Slack is Young and evolving and driven by a single company which wants to push their client

This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business.

IRC definitely has stability going for it but it also means it has been unable to adapt to user requirements changing over time. The most usable IRC client right now is IRCCloud which is good, but it doesn't inspire much hope because it's only usable since they completely plaster over the protocol in their UI.

In this model there's nothing special about IRC except that it's a common denominator protocol for a few networks that use it. If we were choosing a inter-network protocol I don't think anyone today would come up with IRC.

Re: Absence of certain features in IRC considered a feature

#46

Post by Sir_Cmpwn »

maeln wrote: post #41

I love the simplicity of IRC, I still use it to this day, but I have to say, I understand why IRC cannot be used for any serious team communication. The two biggest pain point that I see is: 1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots). 2. No offline history: You have to have a client/bouncer r…

I think both of these are important problems (and number among the issues I alluded to in the conclusion of the article). I hope to see them improved in the future and will provide whatever support I can to IRC networks working on them.

However, if you're going to run your own IRC server you can also run your own bouncer service. Lots of authentication options exist as well. IRC is totally fine for an org who can stand up a server. It's pretty low-maintenance too.

Re: Absence of certain features in IRC considered a feature

#47

Post by nayuki »

zimbatm wrote: post #42

The article doesn't talk about the best feature of Slack: a consistent message history for all the users. In IRC messages can easily get lost due to network splits or client disappearing. Not having everyone with the same message timeline can make some conversations quite awkward. This is really the only feature I miss in IRC.

In exchange, you have gut-wrenching systemwide outages of Slack once in a while. The CAP theorem says you can't have it both ways. News from 3 days ago: https://news.ycombinator.com/item?id=20303479

Re: Absence of certain features in IRC considered a feature

#48

Post by Spivak »

est31 wrote: post #24
Spivak wrote: post #9

Earlier quoted context omitted.

I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad. I've been using wee-slack for a while now and I have very few complaints. I mean it's not IRC where the protocol is etched on stone tablets but Slack has been thus far a good steward of their API.

> I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad. The difference between IRC and Slack is that IRC is seen as a standard protocol while for Slack the network protocol is an inofficial implementation detail and any use other than of the official client is unsupported. I'm not very familiar with Slack, but I've heard about Whatsapp users being banned…

Huh? The network protocol for Slack is JSON over WebSockets and is completely documented and supported [1]. You don't need a Slack SDK to speak to Slack and can do it with any plain WebSocket library.

Obviously Slack doesn't provide support for 3rd party clients; how could they? But they do provide support to the developers of those clients using their API.

[1] https://api.slack.com/rtm

Re: Absence of certain features in IRC considered a feature

#49

Post by johannes1234321 »

Spivak wrote: post #44
johannes1234321 wrote: post #22

Earlier quoted context omitted.

The difference is that the IRC standard is decades old and stable and made for "independent" clients. Slack is Young and evolving and driven by a single company which wants to push their client

This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business. IRC definitely has stability going for it but it also means it has been unable to adapt to user requirements changing over time. The most usable IRC client right now is IRCCloud which is good, but it doesn't inspire much hope because it's only usable since they completely…

> This is all very true but they're also a company that wants to push their API since that's where most of their stickyness comes from as a business.

This is what people said about Twitter as well ;)

And slack, for instance, discontinued their IRC gateways as that limited their possibilities to "innovate" and I can image Slack, being pushed by shareholders, restricting free add-ons to getting data into slack (from Version control, business tools, task trackers, ...) but restricting getting data out to more expensive tiers (making transition of Slack harder)

But there are the key difference between open and proprietary protocols: Open protocols are slow to evolve (see also the state of mail protocols ... where innovation happens mostly in Gmail's protocols, not SMTP/imap/...) but allow wide variety of clients, while proprietary systems can evolve faster, but are more limited in clients.

Re: Absence of certain features in IRC considered a feature

#50

Post by Sir_Cmpwn »

Spivak wrote: post #48
est31 wrote: post #24

Earlier quoted context omitted.

> I mean all IRC clients are 3rd party so I'm surprised that your sentiment towards 3rd party Slack clients is so bad. The difference between IRC and Slack is that IRC is seen as a standard protocol while for Slack the network protocol is an inofficial implementation detail and any use other than of the official client is unsupported. I'm not very familiar with Slack, but I've heard about Whatsapp users being banned…

Huh? The network protocol for Slack is JSON over WebSockets and is completely documented and supported [1]. You don't need a Slack SDK to speak to Slack and can do it with any plain WebSocket library. Obviously Slack doesn't provide support for 3rd party clients; how could they? But they do provide support to the developers of those clients using their API. [1] https://api.slack.com/rtm

I'm going to remind you of this comment in 5 years.
Post reply on HN