I don't use IRC. But I'd never use Slack either in a project I maintain/lead. We need a better alternative.
+m quiets all users in the channel and only allows you to speak if you receive the channel-user mode +v (voice) or have +o (operator status). Some ircds also have a +h etc.
You can setup bots like “RaiseYourHand” for people who want to ask questions and need temporary voice (+v).
Try that on slack, telegram, signal, etc. Its impossible.
IRC was ACTUALLY built for collaboration and communication. Slack was built to make money.
The difference in goals causes a different outcome.
Just imagine how much better Discord, Slack, et al. could be if you could host your own instances with your own rules and with your own extensions.
I do, and I think it's a good constraint (better than the 140/280 char Tweet restriction). No excessive notifications by default, no impatient people (at least largely not because they don't tend to hang around anyway). The pace is more predictable and consistent, and it's easier than ever to have a 24/7 detached client/bouncer.
For some years, fancier services like Facebook robbed creativity and time from me but lately I've returned to a more simple flow that isn't affected by Eternal September.
IRC has a certain barrier of entry, so that tends to keep a lot of the low quality noise away (where it remains on other platforms such as Discord and YouTube).
I recognise that Slack and Discord have their own objectives, but IRC covers its own niche well.
I setup Mattermost for my company. The deciding factor between Mattermost and IRC was effort to get non-technical users a nice GUI. Functionally, IRC would have won.
Additionally not being able to share images as a feature? I guess everyone will do the three step upload to imgur first.
In my world - if I could get away with less different clients I would. It makes it a nightmare to support.
Imagine this:
You have a bot in your channel that accepts an "upload-image" command followed by a base64-encoded string representing an image (or a series of these commands if line-lenght is limited, I'm not sure about this part of the IRC protocol). The bot checks that the image is actually an image (to avoid weird injection tricks), saves it on the server and returns a link you can share or sends the link directly to the user/channel of your choosing.
This can be automated with a irc client, of course. Users using old clients will receive an actual link, users of this supposed new client see a clickable preview of the actual image inline.
And of course it was automated. There are any number of such clients. Slack. Facebook Messenger. WeChat. Viber. Dozens of them. Of course they don't use IRC. But they automate file delivery. And media inlining. And dozens, if not hundreds of other things.
Meanwhile the "nothing stops you from implementing" crowd implements nothing and keeps wondering why basically no one uses these wonderful open protocols.
For example to provide authentication many servers provide a bot called NickServ. There could also be a mechanism called ProfileServ that implements these functionalities.
The beauty of IRC is that you can open telnet, connect to an IRC server and actually be able to chat by typing raw commands.
The problem with IRC is that there is no standard specification, and there are many many edge cases. Therefore in my experience most IRC clients implement a small subset of the IRC protocol.
I've been trying to write an irc client in Go for quite some time (https://github.com/terminalcommand/irc-v2). It's been a fun experience, but there is still a lot to cover.
RFC 1459
The situation is not unlike that of terminal control sequences. The core VT10x functionality is more-or-less mostly in place, ish, in every terminal emulator, but some of the VT10x functionality is no longer implemented, and lots of subsequent useful functionality isn't well documented, so implementors are left to crib from other implementations.
Irc also has a lot of -to me at least- obscure specifications for example involving channel modes. The functionality differs from server to server.
I have the impression that most irc servers are operated by programs with old codebases coded in C. New client implementations are continuing to get written, but I do not see a lot of server implementations around, probably because it is complicated to write.
I mean, this proposal is to build it on top of IRC, it doesn't need to change how the IRC protocol works. We're speaking a level above that.
IRC was, with the exception of simple clients, codable, scriptable, extensible.*
Software today is “what you get is all you get.” It’s pretty sad.
* It was a human body script that caused you to look at this “*”. Scripting is powerful.
That's a feature for me. If I wanted to be constantly barraged with images, I would have stayed using Facebook and Twitter. People on IRC posting imgur links gives me the opportunity to accept or decline (usually based on their reputation, the channel's response, or my boredom). With other social networks, images are almost always unsolicited and often only waste scroll space (good luck to those still on limited data plans and want to know the context of the latest notification).
Besides, text often can have more substance and precise meaning (even if it's not perfect all the time). After all, we're all communicating with mostly just text right here. Another example of something else that features mostly text are books, so it's certainly not deprecated.
Give me all the text please - in fact, if you give me an image with a caption, I'll read the caption first. I can happily find images through other mediums so IRC without embedded images isn't a problem at all here.
Maybe I'm missing the point here: But IRC does have a file transfer feature, so what would stop people from sharing images just the same way like plenty of "content" has been shared over IRC?
Then again, if you want to equate the badness of IRC and FTP, which is much earlier than IRC and much more of a security problem, you're making a poor quality argument anyway. Dumpster fires and garbage dump fires are different orders of magnitude.
IRC being an open protocol and having the option to run your own servers is what makes it decentralized. The various "major" IRC networks (EFnet, Freenode etc) are decentralized too, since they are isolated networks.
Slack offer neither of these - they own all servers, the protocol and controls the API (which is not the same as an open protocol).
IRC on the other hand allows ephemeral usernames, you have the option to use e2e encryption if you choose, etc.
I mean, you do need an Apple ID to do it that way. But I don't think there's anything stopping you from creating throwaway Apple IDs.
Why is that? IRC supports SSL, of course, and many IRC networks offer "cloaks" (to hide your IP address from other users) and/or permit connections via Tor.
I've never seen an ircd cloak instruction page misrepresent what they can and cannot do. While protecting IP addresses is important (which the GDPR also believes in), I think it's also important to not lose perspective of the bigger dangers out there right now such as default user behaviour and conditioning. For example, IRC has never led to huge numbers of people publicly humiliating themselves by bitching about their employers, etc.
Like what outside of taking the scope outside of the IRC client (external link, etc)
An IRC cloak is programmed into the ircd itself ensuring that ones IP address is not exposed. I don’t think you can just hack that. If you use the external link trick, everyone is susceptible to that no matter what app/platform they use unless you use a VPN or Tor.
In any case there are some really obsessed people who probably know a hundred ways to take over your channels at the very least. Seeing some of these people do their thing is one of the reasons why I steer clear of IRC these days.
The Freenode decloak trick still works, though.
1) There are a number of ways to decloak somebody purely via irc/ircd fuckery - though it's liable to require several minutes of dedicated effort to do so.
2) There's a non-zero likelihood that if you try any of those ways we will spot you and k-line you.
3) That likelihood is not a guarantee, so when cloaking people we always make sure to warn them first that cloaks aren't 100% reliable and if users really want to protect their IP address they want a VPS, a VPN, or tor.
4) No, I'm not going to be any less vague about 1, just because it's not actually hard doesn't mean I want to encourage it.
Some networks only let people connect via SSL.
I faced the same problem with IRC that I am facing with Signal today. Though this analogy doesn't really seem that coherent but I hope you see where I am coming from. No one I would like to communicate with via such apps/platforms seems to use it. IRC is great but I would like to connect it with people I know, are part of something I like or do, or are from the place I belong to. They don't. They have moved to other platforms, long back, or never really used IRC.
I believe a lot of existing IRC users, including me, are still around just because of the nostalgia.
For the last 10 years, been working on open source software for a living. Been an IRC user for equally long; `mutt` for the last five years. Thank goodness I do that. Nothing comes close to its effectiveness.
Lack of images on IRC is a feature; not a bug, dammit. It keeps me productive and removes utterly distracting crap. I'd be loathe to see IRC showing images and animated poop emojis (although the unicode 'pile-of-poo' renders just alright on my command-line IRC client, `irssi`).
I can handle video chat and in-person communication equally fine. But I prefer the clarity and vigor of the text-only approach.
"Clear writing is a sign of clear thinking."
I don't use Mutt to get access to my email, anymore, either.
I guess that makes me "average".
IRC, FTP, and, yes, SMTP are all bad protocols from the 1980s era of protocol design. All are on their way out, some more gradually than others. Good riddance. How sad it would be if the Internet of 2020 looked the same as it did in 1995.