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

71–80 of 222 posts

Re: Absence of certain features in IRC considered a feature

#71

Post by derefr »

swebs wrote: post #59
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…

After doing some digging, it looks like there's some people working on a new spec for IRC version 3. One of the additions is the ability to request chat history from the server. Though I'm not sure when it will be implemented since it's been on the table for 4 years now. https://github.com/ircv3/ircv3-specifications/milestone/4/

> Though I’m not sure when it will be implemented

Presumably, when some random IRCd hacker decides to spend their spare time doing so. Most of the IRCds are FOSS, no?

Re: Absence of certain features in IRC considered a feature

#72

Post by KirinDave »

lossolo wrote: post #69
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…

1. Use nickserv and chanserv? This is solved problem. 2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.

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.

Re: Absence of certain features in IRC considered a feature

#73

Post by KirinDave »

ddevault wrote: post #40
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…

As a user of non-English languages, this is not really a problem in practice. We settled on UTF-8 years ago. My second language is pratically the worst case for bumping up against these limits and I never have an issue with them.

Really. So you don't think Japanese folks just don't run into problems? Or Koreans? Or anyone using a primarily upper Unicode alphabet that is phonetic?

Re: Absence of certain features in IRC considered a feature

#74

Post by moftz »

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.

I think you misunderstand the real quality of running an IRC client from anywhere on anything. I don't need to carry around a $4000 laptop to get my work done when I can use my home dev server from anywhere using a 10-year old Thinkpad junker. Break it? Pitch it and buy another for less than $100 on ebay.

Re: Absence of certain features in IRC considered a feature

#75

Post by lossolo »

We are running our own IRC server (UnrealIRCd + Anope for services) for 10+ years. We have bots for gitlab/github, schedulers, management bots (you can basically control whole infrastructure and all services from IRC), event logging channels, alerting, jobs/tasks bots, status checking etc. all with authentication and authorization.

This is working well for us, without any issues for years.

Re: Absence of certain features in IRC considered a feature

#76

Post by Sir_Cmpwn »

KirinDave wrote: post #73
ddevault wrote: post #40

Earlier quoted context omitted.

As a user of non-English languages, this is not really a problem in practice. We settled on UTF-8 years ago. My second language is pratically the worst case for bumping up against these limits and I never have an issue with them.

Really. So you don't think Japanese folks just don't run into problems? Or Koreans? Or anyone using a primarily upper Unicode alphabet that is phonetic?

私の二番目の言語は日本語だよ

Re: Absence of certain features in IRC considered a feature

#77

Post by KirinDave »

Sir_Cmpwn wrote: post #76
KirinDave wrote: post #73

Earlier quoted context omitted.

Really. So you don't think Japanese folks just don't run into problems? Or Koreans? Or anyone using a primarily upper Unicode alphabet that is phonetic?

私の二番目の言語は日本語だよ

This makes it all the more baffling to me. You get 510 a line, but for a channel with a modest name in any other language, you get much less than that.

Let's just use a modest channel name like "#𐑥𐑨𐑔 𐑯 𐑕𐑲𐑧𐑯𐑕". I've now got a base 45 bytes without any message at all. If I want to aim a message at someone I have even less than that. Your pithy reply with a similarly modest title is 20% of the total allocation for a line, half of which is just overhead.

We run into line limits talk about category theory in #haskell even in English and folks are quite good at compressing contexts. The only alternative is to slice your messages across lines and make a confusing experience for participants.

Re: Absence of certain features in IRC considered a feature

#78

Post by chipotle_coyote »

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.

Re: Absence of certain features in IRC considered a feature

#79

Post by lossolo »

KirinDave wrote: post #72
lossolo wrote: post #69

Earlier quoted context omitted.

1. Use nickserv and chanserv? This is solved problem. 2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.

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.

Re: Absence of certain features in IRC considered a feature

#80

Post by swebs »

derefr wrote: post #71
swebs wrote: post #59

Earlier quoted context omitted.

After doing some digging, it looks like there's some people working on a new spec for IRC version 3. One of the additions is the ability to request chat history from the server. Though I'm not sure when it will be implemented since it's been on the table for 4 years now. https://github.com/ircv3/ircv3-specifications/milestone/4/

> Though I’m not sure when it will be implemented Presumably, when some random IRCd hacker decides to spend their spare time doing so. Most of the IRCds are FOSS, no?

Well there's still active discussion on how the extension should work. This needs to be squared away first since you'll need all server software and client software to agree.

https://github.com/ircv3/ircv3-specifications/pull/393

Post reply on HN