Absence of certain features in IRC considered a feature • Hacker News Board

Re: Absence of certain features in IRC considered a feature

#81

Post by chipotle_coyote » Mon, Jul 01, 2019, 3:39 PM UTC

nayuki wrote: post #47

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

There are many ways in which I prefer IRC to Slack, and I agree with Sir_Cmpwn's general premise that some of Slack's features are more trouble than they're worth. (Slack's threaded replies are definitely one of them, and while I've seen better implementations in IRC-like systems, "just don't thread replies" is so far the best implementation I've seen.) But the problem you're describing here is arguably one of Slack's advantages, not a disadvantage.

Re: Absence of certain features in IRC considered a feature

#82

Post by ddingus » Mon, Jul 01, 2019, 3:40 PM UTC

superkuh wrote: post #52

It isn't that the features don't exist. I think most people on IRC just see the internet as their platform. Integrating image hosting into IRC seems absurd when there are perfectly good browsers and ways to host or self host images. Stuffing everything into one client, or worse, one corporation just restricts features and provides a single point of failure in both technical and censorship terms.

I agree, however a simple image copy paste would see a ton of use.

...and a ton of hate.

Re: Absence of certain features in IRC considered a feature

#83

Post by LinuxBender » Mon, Jul 01, 2019, 3:46 PM UTC

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…

For chat persistence, you can use TheLounge [1]

[1] - https://thelounge.chat/ https://github.com/thelounge/thelounge

Re: Absence of certain features in IRC considered a feature

#84

Post by KirinDave » Mon, Jul 01, 2019, 3:59 PM UTC

lossolo wrote: post #79

KirinDave wrote: post #72

Earlier quoted context omitted.

1 doesn't really solve the problem. 2 is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.

> doesn't really solve the problem. Care to elaborate? It solves authentication for us and we are using it for 10+ years like this. > is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works. Let me check my current znc IRC session signon: Wed Jul 18 07:43:12 So almost a year.

> Care to elaborate? It solves authentication for us and we are using it for 10+ years like this

If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.

> Let me check my current znc IRC session signon: Wed Jul 18 07:43:12

Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.

Re: Absence of certain features in IRC considered a feature

#85

Post by danmg » Mon, Jul 01, 2019, 4:03 PM UTC

693471 wrote: post #51

IRC is forever tainted by graybeards that won't give up their terminal clients. People who want to get work done have moved on. The next generation of developers have no interest in IRC. It's a dead end.

Why should text chat need more than a 'terminal client'?

Re: Absence of certain features in IRC considered a feature

#86

Post by bluefox » Mon, Jul 01, 2019, 4:06 PM UTC

IRC is one of the few Internet venues I still frequent. Been using it since 1998. Some years ago an important (but small, private) channel moved from EFnet to Freenode, so that is the network I now use. Seeing Freenode IRCops looking to fix what ain't broken ("but it's opt-in" they'll say..) makes me have doubts about the move. If this sounds "get off my lawn" to you, you're getting it.

Re: Absence of certain features in IRC considered a feature

#87

Post by KirinDave » Mon, Jul 01, 2019, 4:07 PM UTC

chipotle_coyote wrote: post #78

KirinDave wrote: post #58

Now let's talk about the inherent lack of a good centralized identity service, the danger of the majority of IRC servers and clients being written in C and the inefficiency of the protocol itself for applications like high latency links? We might also talk about the lack of important modern features like basic negotiation of client encoding capabilities and what an absolute tire fire DCC-based features continue to be…

I'm not sure if "festues" is a word I don't recognize or a typo for a word that I can't mentally correct into something I'd recognize.

Fixed. Sorry, I've been engaging is user behavior that IRC as a protocol can't support: using a mobile client. I'm still new to going fast with my TAP strap.

Re: Absence of certain features in IRC considered a feature

#88

Post by frou_dh » Mon, Jul 01, 2019, 4:12 PM UTC

Kooky "reaction GIFs" in work chat are so inane. I mean, there's certainly a time and a place for browsing funny GIFs on the web, but making it a first-class part of work chat is so juvenile it's unreal.

Re: Absence of certain features in IRC considered a feature

#89

Post by abstractbeliefs » Mon, Jul 01, 2019, 4:15 PM UTC

bluefox wrote: post #86

IRC is one of the few Internet venues I still frequent. Been using it since 1998. Some years ago an important (but small, private) channel moved from EFnet to Freenode, so that is the network I now use. Seeing Freenode IRCops looking to fix what ain't broken ("but it's opt-in" they'll say..) makes me have doubts about the move. If this sounds "get off my lawn" to you, you're getting it.

You're welcome to come chat to me in ###kline over there, there's some useful upstream discussion on it here as well: https://cmpwn.com/@kline/102333166678467931

Make no mistake, we don't want to change IRC, but we do want to take some of the sharp edges off. I'll never move away from hexchat, the client I use now, and maintaining that backwards compatibility and character for all users is a red line for us.

Re: Absence of certain features in IRC considered a feature

#90

Post by abathur » Mon, Jul 01, 2019, 4:16 PM UTC

This reminds me of what Apple does to the SMS/MMS ecosystem.

MUDs face a similar set of issues. Some new MUD frameworks skip over these by ignoring telnet and going HTML/JS.

There's an interesting third path, GMCP, which is basically treated by the server/client (once support is negotiated) as out-of-band communication. If either end can't negotiate support, you get the basic experience. As a pressure-release valve, options like this can be better than clients or servers trying to overload the primary protocol with magic messages that other servers/clients without support are still forced to digest and display.