1. 41
  1.  

  2. 15

    Long live IRC! I have been using it for 12 years and have always loved it for its simplicity. It follows the UNIX philosophy for being able to do one thing (communication) and doing it well, but I feel like some people would disagree with me.

    1. 7

      Couldn’t agree more (although the first time I used it was 1993!). It’s far from perfect and the barriers to entry are higher than they need to be, but it’s works well for the most part.

      It does make me sad that a lot of the discussion that used to happen on IRC has moved to Slack (and related proprietary tools) in certain communities. Yes, some of those tools do have IRC bridges but if you use them you’re always a second-class citizen. Not to mention at the mercy of a commercial company who can pull the rug out from under you at any point (cf. Google Chat and XMPP support, for example).

      1. 4

        you’re always a second-class citizen

        I used an Hipchat->XMPP->IRC bridge at my last job, and one of my favorite features was that it didn’t subject me to emojis the way the official clients do.

      2. [Comment removed by author]

        1. 8

          irccloud does pretty well in this area, I think.

          1. 4

            Having run my own bouncer in the past, I love, love, love IRCCloud. I’m happy to pay them $5/mo to make everything just work. And I can stay logged into the mobile client without a persistent connection draining my battery.

            1. 4

              Yeah, I wish the desktop web interface didn’t bog down so much under load – but the mobile stuff is amazing.

      3. 9

        The ad choice might be relevant, but it’s not appropriate…

        1. 6

          I’ve been using IRC constantly since around 2008. I love it. I think the reason it sticks around just the network effect. The protocol itself isn’t that valuable to me. The network (channels full of friends, bots, infrastructure, clients and chat log history) is very valuable to me. The other options just aren’t very compelling to me. I actually have to use slack and hipchat daily. Hipchat recently broke for my entire team because they use a js/html webview for everything and a js regex went exponential on me. I also am getting tired of seeing the “you’ve reached the end of your free history” message.

          Slack still blows my mind. It seems like the most common way to create a “public” channel is to run heroku apps that auto invite people. And somehow this is seen as a “user friend” “easy” solution for open source project collaboration? I’ve also seen my share of Javascript Core related dumps when their webview based app segfaults.

          Anyways. I get that some people find hipchat/slack easier to use and like the default image display and searching better. Those are important features. For me the killer feature of IRC is a decade old history and ecosystem.

          1. 4

            More than 10 years of IRC here and I’m still more active on IRC channels than anywhere else.

            1. [Comment removed by author]

              1. 1

                The only real problem I have is with meaningless discussions and people talking about things I don’t like without me being able to effectively filter it out. And that the inherent liveliness of IRC makes it a wonderful place for pointlessly killing years of your time if you don’t have the self-control.

              2. 3

                Long URLs are not clickable since they wrap multiple terminal lines

                Pro tip: <M-l> (lowercase L)

                1. 1

                  Give this plug-in a try : https://weechat.org/scripts/source/urlserver.py.html/

                  It works extremely well, and doesn’t hide the original link.

                2. 2

                  This is the type of workflow that I think matrix.org was meant for.

                  My only concern so far has been the security of private channels - if I hook up bots that can spend money, or control physical items around my house, I would hate for someone to see what I’m saying. IRC has the same fate here, it seems.

                  1. 1

                    One thing I dislike about matrix.org is the high-overhead transport (https). Yes, there are other transports in the works, but http will always be a baseline and I just don’t think making a http request for a small two-word message is sensible.

                  2. 2

                    Glad this was written. Good to see fellow IRC enthusiasts out there. I have used IRC for 15 years, and have been using Slack at work for a few years now. I favor my IRC client (Textual) much more than I favor my Slack client, giphy integrations and all.

                    For me, the fact that Slack is closed source with no API to implement clients against kills it for me. It does not reverberate with the trajectory of the open web. It is a business first. Whereas IRC seems closer to an open telecommunications protocol, like telephone or radio.

                      1. 1

                        I really like this as a concept but it’s bad enough that anyone one on a few IRC networks can talk to my (presumably insecure) IRC client running as my userid. Are there any pledge-friendly clients I missed?

                        1. 4

                          Are you sure you’re not being absurdly paranoic?

                          Most insecurity happens at the server-client level. It’s not other users you should be concerned with, as there is practically nothing complicated in the text processing. The attack surface is incomparably smaller to a typical web browser. Also, you could very well run it under a special user.

                          I thought about adding pledge to my IRC client but it’s not really happening: FS write for configuration and log files, FS read for lots of things, networking, tty ioctl for wiindow size detection, fork/exec for helpers (my way of solving scrollback), sysctl for machine information… And of course, whatever my dear user decides to put in scripts.

                          The only reasonable approach to solving the problem is splitting the functionality to multiple processes, making clear boundaries between components, and that ridiculously complicates the already complicated application: handling of custom protocols, asynchronicity…