1. 18
  1.  

  2. 4

    I run an IRC bouncer as well for me. What’s quite neat is that there is the Palaver app on iOS (costs a bit, but worth it) which has a ZNC module on GitHub that you can load and it gives you push notifications on your phone! I think that’s super neat.

    1. 3

      That’s a clever way to deal with notifications.

      I use znc-push, which does a similar thing but it’s not integrated with an app, so you need a push service to go with it. I use gotify for loads of stuff for this purpose, but not everyone would want this.

    2. 1

      I’ve always considered IRC bouncers a cludge. For the longest time I ran irssi in screen on a shell. There was lag typing. Then came mosh, which helped. Quassel has a nice model, where you can run the IRC client on a server and the interface locally. But I haven’t tried that. These days I just use matrix and the irc bridges offered by matrix.org (freenode) and SNT (ircnet).

      1. 2

        I’ve been using screen + irssi for years. Works well enough for me.

        When I got a job again I might consider paying up for IRCCloud. It’s quite slick.

        1. 2

          I’ve always considered IRC bouncers a cludge.

          May I ask why? It’s always seemed fairly elegant to me - have a server act as a client to an IRC server and have virtual channels, exporting an IRC connection out the other side.

          Quassel has a nice model, where you can run the IRC client on a server and the interface locally.

          Isn’t this pretty much what a bouncer does? The client runs on a server somewhere and you pick your own IRC client as the interface?

          These days I just use matrix and the irc bridges offered by matrix.org (freenode) and SNT (ircnet).

          Am I misunderstanding something, or isn’t this essentially a bouncer as well? It sits on a server somewhere and you connect to it with your own client. In this case, it’s something like riot rather than an IRC client, but it’s the same concept with an additional protocol to act as the bridge.

          1. 4

            The difference between an IRC bouncer and the other solutions mentioned (here I’m guessing at how Quassel works though) is that there’s tighter integration between the client and server.

            Here’s an example: when you connect to an IRC bouncer, you get playback of the messages you missed. But all of those messages have the wrong timestamp, because from your client’s perspective, they all came in within a minute or two of when you connected to the bouncer. You can set your bouncer to send timestamps to the client (this is what I do), but there’s no way for the bouncer to “correct” the client’s timestamp, so all it can do is add the timestamp as part of the message. So what you get is two timestamps. E.g. let’s say you connect to the bouncer at 12:30:

            12:30 <someuser> [09:45:00] luser: you around?
            12:30 <luser> [09:53:00] someuser: yes let's discuss the foobars
            12:31 <you> I just connected with my bouncer. it's 1 minute after I actually connected because there was such a flood of IRC playback messages that it took a while to settle and this message wouldn't send until it did.
            12:35 <you> cool, I've been connected with my bouncer for about 5 minutes now
            

            IRCv3 is supposed to help fix this, but it’s not here yet. At least not in my out-of-the-box ZNC + ERC combo, although I will admit that I’m sure IRCv3 is not high on ERC’s priority list 🙄

            Contrast this with Matrix where no matter when you connect, your client always gets the right timestamps because what the client is doing is properly synchronizing with the server. The details from the origin IRC server’s message - like timestamps - are preserved and sent down to the Matrix client.

            I’m picking on timestamps here, but there are a few other problems like this too. For example, it’s annoying when your IRC bouncer disconnects but your client thinks you’re still connected just fine, so the UI desynchronizes with reality. Not sure if Matrix fixes that, although it could. I’m just not familiar enough with it to say.

            1. 2

              IRCv3 is supposed to help fix this, but it’s not here yet.

              I can’t remember if they’re on the standard version of the protocol yet, but Hexchat knows how to get the correct timestamps out of ZNC, so it’s there for at least some clients.

              For example, it’s annoying when your IRC bouncer disconnects but your client thinks you’re still connected just fine, so the UI desynchronizes with reality. Not sure if Matrix fixes that, although it could.

              It couldn’t. I could rant for days about this, but I’ll try to keep it specific. Matrix bridging works by creating a room on the Matrix side and trying to keep it in sync with the IRC side; individual bridged IRC users are a protocol-level fiction in some sense. It tries to monitor what’s happening to them and effect the equivalent changes on the other side, but it doesn’t always know how. The failure modes of this are generally worse than the bouncer model because the latter treats IRC connections individually. For example, if ZNC fails to join a channel for a reason it doesn’t understand, it just won’t join the channel; if a Matrix bridged user tries to do the same they’ll think they’re in the channel (and receive messages from it) until they try to speak. Until about a year ago, you could part channels with !cmd and the bridge wouldn’t notice, setting up the same condition. This will still occur if the bridge doesn’t have enough power level in the Matrix room.

              There remain dozens of outstanding issues that could be described as desyncs on the matrix-appservice-irc tracker. Whatever other benefits of the model might exist, I don’t think maintaining synchronization with reality is one of them.

              1. 1

                Exactly. And matrix also allows requesting more history from the home server to the client. And connecting several clients to the same account.