> UnrealIRCd (a popular IRC server implementation) have actively refused to add features in to the code-base that allow IRC operators to snoop on private messages or covertly on channels, for example.
Someone should have told Angrywolf. This module was on every "we used to be on BigNet but we split off because reasons" UnrealIRCd network for a while, haha
> UnrealIRCd (a popular IRC server implementation) have actively refused
That's really moot because operators can certainly and easily snoop the traffic on the wire. Therefore I agree with the statement above that one should take IRC for what it is: lightweight, convenient, but don't assume any privacy - and it can be perfectly fine.
Most IRC networks are relatively small and/or are/were run by techies with no real incentive to log everything. Also, almost everything culturally about IRC relies on trusting the IRC operators to keep things running smoothly and moderate appropriately.
UnrealIRCd (a popular IRC server implementation) have actively refused to add features in to the code-base that allow IRC operators to snoop on private messages or covertly on channels, for example.
Slack, Facebook, Reddit, and whoever else we all use these days, keep every private message ever sent logged for all time and this is just accepted.
> user accounts and profile pictures by default: Don't want it.
You may not, but many others do, like myself.
Lets be frank, IRC is boring without content. There is no easy way to share any imagery, videos. Any form of simplification of media hosting is a tragic mess.
> Never had an IRC server want to verify me through SMS or FORCE me to update my client.
NickServ.
"If you don't register your nick in 1 minute you be renamed to "anonymous".
I've been on networks where mIRC has been banned which is my client of choice.
> Many IRC networks evolved to have some form of identity verification through nickserv
Some IRC networks do, but it's always an ad-hoc extension. IRC qua IRC doesn't.
> there were many umbrella servers that would be used for various communities to call home in a proto-Discord world.
Did those have channels that passed blacklists around and would ban you on other channels' say-so, or because you were in channels they didn't like? I'm sure there were some channels that did, but it certainly wasn't seen as a positive.
> They maintained a blacklist of hosts that were compromised in case of spyware, or if users were particularly prolific and abusive across networks.
That's not the same thing at all. I'm talking about getting banned on one server just because you joined another server.
> It forces attackers to use a active attack rather than a passive one.
The MITM or eavesdrop can happen on a bridge. If the client doesn't check the certificate and accepts any, its about as good as plaintext. It could be worse, even, due to the false sense of security.
> Which is the only security most IRC can have anyway, since the attacker could just join the channel and listen in that way, since most IRC networks are public.
IRC network private or public is irrelevant.
There were, for sure, private channels back in the days (90s). Back then you could set a channel secret (hidden) and set a password on it, effectively making it a private channel (would not show up in /whois or /list). Bots could kick people who are unknown based on filters. For example, without an auth to an Eggdrop, you could get insta kickbanned even _with_ the correct password.
Then there's PMs which are one on one (except for server(s)).
If one of the IRC servers is compromised though (or tapped, or whatever), that makes sniffing a channel or PMs child play.
There's also the problem of data integrity. If you are asking for (or giving) help in #linux and someone can change the data on the fly, [...]
FWIW, UnrealIRCd, even back then, innovated (or invented) a lot of new features on top of IRC. Some of these added security, though I don't know examples out of my head.
> IRC is just a ban list, an except list and an invite list.
Now use that to implement RBAC for a server with a hundred channels.
Go ahead, I'll wait.
Less pithily, IRC's built-in permissions may be simple, but they're so simple primarily because they're basically useless for real moderation tasks. Every IRC channel I've ever seen handles moderation with a mod-bot, and "set up a bot" instantly blows the complexity budget.
IRC is for public channels (and supports direct messages). It’s far from perfect, but I wouldn’t call it terrible; it works very well for its original purpose (and has been for almost 3 decades now).
IRCd developer and network staff member here. Dead wrong. I don't think I've seen a single IRCd that keeps logs, and doing so would make it much more expensive to run an IRC network. Additionally, it would be a huge violation of privacy, and we value our users' privacy. The IRCd only logs server events (e.g. network-wide bans, server connection/disconnection, use of administrative tools) and user connections/disconnections (for anti-abuse purposes).
If network staff have logs of something, it was either because their IRC client was present in the channel or because someone else gave them logs.
Most of my network's servers hang around 2-3% CPU usage and <5GB disk usage, and we'd like to keep it that way because we don't want it to cost a lot to host. We have an average of 1000-2000 users per server.
> Also, since it appears to be a new & custom irc server, i'd not really be willing to trust corporate communication on a platform known for attracting hackers.
> Obvious troll.
I wonder why did the popular media portray IRC as a hacker hangout, when yahoo messenger rooms and other group chats are implementation of the same concept.
> Unlike IRC which is basically just a bunch of sockets and IPs passing data without storing state
To be honest this is probably reason #1 why people stopped using IRC. We want to see the messages that were sent while we weren't here. Yes I know what a bouncer is, no this is not a good solution.
IRC as a protocol is simple and elegant but as a product it doesn't meet today's users expectations at all. And you can't just say users expectations are wrong and they should just align with what IRC provides, it doesn't work like that.
> For IRC, logging is outside the scope of the IRC protocol.
Nope, the community has understood that server-side logging (and making it available to clients who missed stuff happening) is a useful thing. https://ircv3.net/specs/extensions/chathistory
>IRC has had encryption for a very long time. IRCS is typically on port 6697 but some admins also have it listen on 443 for people behind fascist firewalls.
Transit encryption maybe, but admins can still read everything.
Unless you have a mobile keyboard you'll have to search for emojis yourself and paste them. Emoji's will always be an after thought unlike in Matrix[1] and riot[2].
>>Search
You're right, it has nothing to do with the protocol. It was never about if it was possible or not. I'm talking about if it is available right now. Try riot.im and then please show a mainstream IRC client with has the same search features.
>>Session persistence
>No, nobody wants this.
Really? Are you sure?
> The former is solved by the same server-side logging mentioned above and the latter is really the same idea. The thing is, most IRC servers don't want to buffer messages indefinitely for everyone that makes an account then never logs in again.
Again, this isn't about if it is possible. It is about if it is available right now. You seem to be a big fan of writing code by yourself for features. Please link me to the cool IRC client you use which has all these features.
>>> Web Client
IRC was never intended to be run in the web browser. But matrix was built with that in mind. This is what my ' And IRC feels so hacked on when fit it with the modern features one wants today' comment was all about.
>IRC has lots of features that are much, much more complicated than what you mention above, like DCC file transfer.
Honestly, I might sound ignorant, but I've never ever heard of DCC file transfer. And matrix has implemented E2E encryption in some of their clients(all the major ones), and implementing them in the rest is a priority. I don't ever thing IRC will have this. I'd be glad if I was wrong.
Also, why the boast about 'much, much more complicated'? What features require so much complexity, and if they did require high level of complexity, how useful are they? Also IRC doesn't think a lot about the UX/UI part which is what I often am frustrated about.
One thing I find interesting about your reply is that you seem to assume the user is an experienced programmer. You make suggestions about extending an IRC server feature like it's changing a setting. But most people who are in OSS wouldn't bother with that. And what about non-technical users? Shouldn't this be easy to use for them to?
Or do you want to ignore them so that they continue using a closed messenger and wonder why they're dominating the mindshare today?
Have you wondered why a lot of OSS projects moved to slack? I'm surprised no one in this thread is trying to find out why IRC doesn't seem to be the choice of OSS projects. Rather it seems to be about bashing matrix and one-upping IRC over matrix. Which solves nothing.
Your missing the point on the fact that IRC is all text. All you could ever do send links. It worked but sucks from now future on.
Nowadays where do you host those links? Github? Sure. But the FAFF of setting up a github static wank account. find some lets encrypt cert bot owned by google which expires every six months. Your going to do all that for one IRC Link?
In the days before tumblr, the simple days of MSN/Yaho. When IRC was active and flourishing. You could just send a link from your own server, a server in your bedroom. Sitting on your home 56k IP on a http server without needing any cert, any annoying messages, cookie banners to a user.
Those days are over. I know, but it hasn't gotten easier. IRC it's sitting right there, the diamond.
Someone should have told Angrywolf. This module was on every "we used to be on BigNet but we split off because reasons" UnrealIRCd network for a while, haha
https://pastebin.com/EVkudZVb
(disclaimer: don't use it for moral reasons, but also because I've not vetted the code in any way beyond checking it looks a bit like code)
reply