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

141–150 of 222 posts

Re: Absence of certain features in IRC considered a feature

#141

Post by dfabulich »

ganzuul wrote: post #119
KirinDave wrote: post #70

Earlier quoted context omitted.

Indeed, the dependence on a persistent connection itself is an absolute non-starter for this feature. It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.

Having been on IRC for maybe two decades now, I find the impermanence to be part of IRC's charm. People engage with you when you ask them what has been going on; just like in real life. It's a social protocol.

The post you're replying to isn't referring to "impermanence," it's referring to messages dropped in transit. IRC is an unreliable message transport even if all users are online and trying to listen to each other.

The most obvious version of this is a netsplit, but even single users can get isolated from the network and have all of their messages dropped without realizing it until minutes later (if ever). There's no cool name for that; it's just IRC being unreliable.

Maybe unreliability is part of the charm for you, but that bug is absolutely not a feature, and not intrinsic to being a "social protocol."

Re: Absence of certain features in IRC considered a feature

#142

Post by nxrabl »

phicoh wrote: post #133
glacials wrote: post #124

Earlier quoted context omitted.

The author specifically calls out ephemerality as a feature of IRC. If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone. By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.

And then lots of people have bouncers to be there 24x7.

Which makes for an interesting dynamic, since it's the people with the most experience for whom the chat is least ephemeral, and the people who would benefit most from having scrollback who are least likely to have it set up properly.

Re: Absence of certain features in IRC considered a feature

#143

Post by buzzert »

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.

What are some good channels to visit in 2019? I feel like most of the ones I used to frequent are dead silent now. And my small friend channels have since moved to Discord.

Re: Absence of certain features in IRC considered a feature

#144

Post by Etheryte »

phicoh wrote: post #133
glacials wrote: post #124

Earlier quoted context omitted.

The author specifically calls out ephemerality as a feature of IRC. If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone. By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.

And then lots of people have bouncers to be there 24x7.

Personally, the main benefit of a bouncer is not missing highlights when someone wants to turn your attention to something interesting, reading up the logs for even a single channel isn't a reasonable way to invest your time.

Re: Absence of certain features in IRC considered a feature

#145

Post by dfabulich »

The article here claims that IRC is better than Matrix because Matrix supports pasting long snippets and IRC doesn't. The author furthermore claims that Matrix users are being a "nuisance" by posting long snippets to IRC with a link fallback, like this:

    ihabunek [m] sent a long message: 
    ihabunek [m] uploaded an image: image.png (39KB)
This is "being a nuisance"? It's just two chat lines, and the first line isn't meaningfully longer than a link to pastebin. Maybe pasting the image was a bit excessive, but it's very likely to be auto-expanded in GUI IRC clients, making it an excellent fallback. It's not "being a nuisance." It's two links. It's fine.

The truth is, IRC folks do need to share long snippets and images, and they do it by linking to them; that's exactly what Matrix does when integrating with IRC. That's one among many reasons that Matrix is better than IRC.

Re: Absence of certain features in IRC considered a feature

#146

Post by duskwuff »

pmlnr wrote: post #56
crankylinuxuser wrote: post #36

Earlier quoted context omitted.

IRC was made a spec in 1993. Not 2003, or even 2013. And when that RFC was made, they made strong decisions about bandwidth costs. They gave up things like federation and more. So yeah, it's time that it's revisited in making a IRC that can be federated, multiple login/endpoints without using bouncers, and more. I welcome their new RFC. And it it doesn't work, we're free to keep what we currently have.

What you're after is called XMPP.

No, it isn't. XMPP was designed primarily as an IM protocol to replace proprietary messengers like AIM and ICQ, not as a service for group chats. It's a flawed protocol even for IM, and its conference features verge on broken. (For example: A user's visible presence in a conference is neither necessary nor sufficient for them to send and/or receive messages in the conference.)

Re: Absence of certain features in IRC considered a feature

#147

Post by ganzuul »

dfabulich wrote: post #141
ganzuul wrote: post #119

Earlier quoted context omitted.

Having been on IRC for maybe two decades now, I find the impermanence to be part of IRC's charm. People engage with you when you ask them what has been going on; just like in real life. It's a social protocol.

The post you're replying to isn't referring to "impermanence," it's referring to messages dropped in transit. IRC is an unreliable message transport even if all users are online and trying to listen to each other. The most obvious version of this is a netsplit, but even single users can get isolated from the network and have all of their messages dropped without realizing it until minutes later (if ever). There's no…

You are correct. IRC is not airtight.

You do however get informed by the server after a netsplit has occurred... and key-up retains most of what you have said recently so achieving coherency isn't difficult, although a manual task.

Re: Absence of certain features in IRC considered a feature

#148

Post by Sir_Cmpwn »

dfabulich wrote: post #145

The article here claims that IRC is better than Matrix because Matrix supports pasting long snippets and IRC doesn't. The author furthermore claims that Matrix users are being a "nuisance" by posting long snippets to IRC with a link fallback, like this: ihabunek [m] sent a long message: ihabunek [m] uploaded an image: image.png (39KB) This is "being a nuisance"? It's just two chat lines, and the first line isn't mean…

I expanded on this here:

https://lists.sr.ht/~sircmpwn/public-inbox/%3Ca6e64b69-c0cf-...

Re: Absence of certain features in IRC considered a feature

#149

Post by rhizome »

KirinDave wrote: post #99
ohithereyou wrote: post #96

Earlier quoted context omitted.

1 is trivially solvable on the server side by requiring TLS+SASL 2 is trivially solvable on the server side by writing logs IRC is a protocol, not a product, and an IRCd author can add these features. The fact that it has not been done speaks to the demand for these features.

I would not call running those services "trivial", but yes. If you bolt actual authentication onto something below L7 of the protocol, then you get real authentication. However, it's difficult for permission models to properly integrate with this, which is why many servers still support nickserv. > Logs Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra softwa…

>Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.

I don't understand, is this referring to running company chats on EFNet or Freenode or something? IRCd can be run locally, on an inside server or other controlled execution environment.

Re: Absence of certain features in IRC considered a feature

#150

Post by ganzuul »

asveikau wrote: post #140
ganzuul wrote: post #119

Earlier quoted context omitted.

Having been on IRC for maybe two decades now, I find the impermanence to be part of IRC's charm. People engage with you when you ask them what has been going on; just like in real life. It's a social protocol.

But the lack of reliability I described a few comments up is not just a problem for 24/7 archiving. You will see it in everyday use: your connection will drop, it will take a while for a timeout to notice, and you will miss messages for that period. Now in a real life situation you can mishear or fail to hear. But technology can make this better.

I meant to address the second issue you bring up; that you ask if you missed anything during the period.

I might not want a 24/7 archive. Especially not for all the silly things I said in my teens.

Post reply on HN