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.
Absence of certain features in IRC considered a feature
51–60 of 222 posts
Re: Absence of certain features in IRC considered a feature
#52It 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.
Re: Absence of certain features in IRC considered a feature
#53> 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?
I can only speak from experience, but Thai language uses 3 bytes per character in UTF-8 and rely on vowels and tone marks to compose a word, so the number of bytes can grow pretty quick. A headline of an article in Thai have a good chance of exceeding 510 bytes.
This is why one of the major Thai IRC networks were stuck with TIS-620 for a long time (ThaiNet/irc.thai.com, though I'm not sure if this is still the case) which is 8-bit compatible with ASCII (uses 0xA1 to 0xFB for Thai characters).
Re: Absence of certain features in IRC considered a feature
#54> 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?
Cyrillic symbols are encoded in UTF-8 with two bytes. You limited with 255 characters.
Re: Absence of certain features in IRC considered a feature
#55Earlier quoted context omitted.
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 Ve…
Well yeah, I'm in no way saying that people in the OSS world should standardize on single company's proprietary protocol and platform and if IRC is the only thing people from two projects can agree to speak then it's what we've got.
But we really need to stop trying to make IRC 'work' and build something more usable that can interop with existing IRC networks (hi Matrix!). IRC is fundamentally not a good enough protocol for how people people chat today but it's easy for people who have been using it for 20 years and have a lot of pride and machismo sunk into figuring it to dismiss outsiders that are struggling and believe that if you pile enough barely-working brittleware on top that it can sorta-kinda work like Slack or Mattermost.
Re: Absence of certain features in IRC considered a feature
#56IRCv3 is a scourge because of this. They’re looking to bloat the protocol. IRC is good because it’s IRC.
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.
Re: Absence of certain features in IRC considered a feature
#57IRCv3 notwithstanding, the protocol from a software engineering point of view is horrible. It doesn't support asynchronous operations because responses cannot be tied to their corresponding requests, and many commands, successful or not, require a human to parse. Too bad that IRCnet only runs whatever has been written down in an official IETF RFC.
Despite all these deficiencies it's still widely used – My guess is that nobody has come up with a chat medium that would replace it completely. It's still pretty much the only decentralized, push-pull, clutter free real time discussion medium.
Re: Absence of certain features in IRC considered a feature
#58Now 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 due to the "just link to an external website" mentality that stifles all discussion of replacements?
Re: Absence of certain features in IRC considered a feature
#59I 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.
Re: Absence of certain features in IRC considered a feature
#60The 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
Are you living in a world without netsplits?