Finally decided to make the effort to optimize my IRC setup, looking for suggestions (detail inside) reddit / irc ---------------------------------------------------------------------- i336_ · 2015-02-16 02:08 Hey everyone. First post here :) I've finally decided to do a bit of poking around and see what I can do about my horribly unoptimized IRC setup which I've been doing my best to put up with for years but finally need to properly fix. My requirements are technically very simple but have a lot of contextual background behind their rationale; the History/Context section is not required reading though. Following that, I explain the ideal setup I'm going for, and finish by detailing my current (rather poor) configuration.   ## History/Context I started using IRC back in 2006. After trying various clients in rapid succession, I fairly quickly discovered HydraIRC. It's a pretty basic client, all up, but the one killer feature that nailed HydraIRC for me was its global channel monitor. I set this to occupy the entire upper half of the program window, the channel-selector tabview sat in the middle, and whatever channel I was typing into occupied the bottom half. It might *sound* like a really inefficient use of space, but FWIW, it wasn't all *that* bad... and I loved it.   Then I switched to Linux.   That was... yeah, that was a bit of an... *adjustment*, to say the least; when I switched in 2008 there wasn't really anything for Linux that provided "all my channels/PMs grouped in one view I can put at the top of the screen, with the the current channel positioned underneath" out of the box. On top of that, I adamantly limited my options to something I could run on a remote machine, so I could reboot, kill X, reconfigure my system, etc without losing my IRC state, so I wouldn't lose my train of thought and I could roll straight back into the active discussion when I came back the next morning. Insisting on remote execution has served me well in the months and years since - being able to SSH in from friends' PCs, display phones at shops, or the local Apple store, is definitely very cool. :P Weechat wasn't as much of a thing when I switched (at least not as far as I remember being aware), so I ended up using Irssi, and learning... how to operate on the edge of tolerance. I didn't like it, didn't enjoy using it, it felt clunky to me, I found various showstopping bugs that turned out to be design "features", I got chewed out by the support channel for hand-editing my configuration file... fun times. But I put up with it. I made my own layout and color scheme, which I use to this day. I aliased `/alias` to `/fix` and built up an autocorrect list that still serves to fix the worst of my typing misteaks (although the lack of regex support in the alias mechanism actually vies for a majority of my irritation). More recently, though, I've finally accepted that Irssi is just an IRC client, it does what it does, and it's not altogether *that* bad. It's not really its fault I didn't know Perl in 2008 and didn't want to learn Perl to "fix" my "broken" IRC client by adding admittedly nonstandard features. That said, Irssi ***is*** pretty old. Weechat is much newer, and a very attractive option to switch to.   Before I commit to a particular program and spend the time to customize a solution around that program, however, I think it'd probably be a good idea to hear out people's suggestions and advice about things I can consider/factor in to make my life easier, and get some perspective and objectivity.   ## What I'm looking for - **Persistence**   I turn all my computers off at night, to reduce electricity usage and marginally lower the amount of background electrical noise in the house while I sleep. Since I want to keep my IRC session active, I need some form of proxy.   - **Individual window detachability**   I'm listing this feature as high priority because I would really, really like to get this working. I just have absolutely no idea how it would [be made to] work.   - **Multiline input box**   Weechat provides this, but is a requirement going forward, whatever I use. More than... a *few* bad experiences with being "multiline verbose" have trained me to compound my thoughts into one line :) - but Irssi's singleline input area has foiled and defeated my attempts to be coherent and remember exactly what I've typed even as it scrolls offscreen, more times than my embarrasment cares to remember.   - **Global message window**   I'd like to get a HydraIRC-esque channel monitor, *with the monitor displayed in a smaller font than I use for the active channel*. This is not "just because" I used to use a smaller font for the channel monitor in HydraIRC and I vaguely think it would be cool. It's because: - If I'm going to adequately keep an eye on **ALL THE THINGS**, I either need to get a massive screen (...not going to work with a laptop), never stop watching IRC (.....), or use a smaller font (ah, the sane option).   - I don't really feel like giving myself long-term eyestrain for the area I ***do*** plan to do most of my typing in, so it is vital I use a different font for this area.   It would be nice to be able to change font sizes for both areas relatively easily.   - **Sane/hackless state/context preservation**   Using systems like ZNC *will* give me a scrollback buffer upon reconnect, but when I do so I get two sets of timestamps in my "catchup": my client's, which are invalid, and ZNC-augmented time information displayed as part of the message. I *suppose* I can get used to this, but it's kind of annoying.   - **Optimal bandwidth usage and minimal lag**   The alternative to ZNC is of course to run Weechat or similar inside a `tmux` session over SSH to somewhere else. This would give me perfectly preserved screen/scrollback/*everything* state.   The "somewhere else" would need to be in the same country as me, however - the machines I currently have access to are 14000+km/9000+mi away, and I can *distinctly* tell. Remote access to a system only a few kilometers away from me is in the works though (where response speeds are very literally equivalent to typing in local terminals! o.o), happily.   The one thing I remain uncomfortable with, though, is that due to the way Weechat controls the screen, ncurses cannot effectively use VT102 escape sequences to optimize bandwidth usage, and as such, every screen update would check in around a minimum of approximately 2KB (~2000 bytes) of bandwidth, and on top of that, every message I sent to IRC would count for twice as much the bandwidth as the message content, because SSH works by transmitting keypresses to the remote system and then waiting for the keypress to be interpreted and displayed, also according to instructions from the remote system. By comparison, messages on IRC are strictly <512 bytes, typically 80-300 bytes. This is an issue I must take into account because I'm in a 3rd-world country when it comes to Internet, to the extent that counting every kilobyte actually does make a difference (:/); I would be very unlikely to leave IRC open if I used it remotely like this - even... even if *was* fast. :(   - ***Ultra*-light-weight-ness**   I have a tendency to use older computers and system configurations. Right now my main desktop is an 800MHz Duron with 620MB of RAM. There are faster systems in the house, but I don't really use them, instead preferring to focus on software efficiency. As such, I tend to avoid anything that uses GTK2 or Qt 3/4; gravitating towards programs that use GTK 1.2 or Qt 1/2, FLTK, plain Athena/Xaw or straight XCB/Xlib for display (xterm/xvt use Xlib so my whitelist includes terminal emulators). It is for this reason I recently switched from Openbox to FVWM, for example - the former proved too sluggish long-term for me to justify continuing to use it.   ## What **won't** work - Remote Weechat inside tmux fails on the bandwidth and multiple-font- size requirements - In case you're wondering, Xterm's VT100 double-height-character option wouldn't work, because it only adjusts the *height*, not the *height and width*, which is kind of what I'd need to be going for to eliminate eyestrain. :P - HexChat can't display more than one view on the screen at once, so wouln't work for me at all.   ## I'm considering I could... - Use an IRC proxy that will allow me to send back custom lengths of history, set per channel (so I don't download all of eg #ubuntu from the previous night, which I am unlikely to ever need to catch up on); PSYC would probably fit the bill here. From there, a pair of scripts, one for the proxy and one for the local client, would auto-negotiate some form of protocol that causes the timestamps in the client to be dictated by the proxy when the proxy is replaying its "catchup log" upon initial connect.   - Use FVWM to group two `xterm` windows, one horizontally one above the other into a single window, and write a Weechat script to stream the global channel/PM log to the upper window in realtime. `Xterm` allows for easy font size change via Ctrl+Click menus.   - As an alternative to the above, I understand Reice can display multiple groups of IRC buffers simultaneously, and since complex font and graphics management is native to Emacs which uses Athena as its toolkit, and which Reice is based on, this would handily fulfill my requirements for a global monitor that used a different font than the input area and "main channel". I'm not actually sure if Riece can be configured for a multi-line input area, though, and I am a bit too indimitated to ask, because I've never used Emacs before. :P   ## My current configuration Right now, I'm using Irssi inside GNU Screen, along with a really hacky/flaky notification system I *really* need to redesign... and not really much else. I've deliberately kept my configuration spartan for months because I've been holding off doing anything with it because I know it's so... broken. **:/**   ## Close As you can see, my requirements are comparatively very simple, but seem to fall into the purview of a very difficult to solve niche. For what it's worth, this isn't the first time I've encountered UNIX's philosophy of "oh, we never realized doing it that way could be elegant... congratulations, you win *ONE (1)* C compiler!" :P   I don't mind making effort - really. I just don't want to make a truckload of investment if there's some better way than what I've thought of, or some tool that could hack into being of assistance to make my job easier (whether that job is happily using IRC with a tool I was completely unaware of, or implementing the customizations I want).   ^(Thanks for reading! :D) ---------------------------------------------------------------------- Crendgrim · 2015-02-16 03:19 Have a look at [Quassel IRC](http://quassel-irc.org/), that sounds like it would fit your needs almost perfectly. It can run in a server- client setup (with the quasselcore on a separate machine); it has a status window that you can configure to show messages from all channels / a subset of them / only highlights. It does not support multiple windows, but in the worst case you should be able to connect two instances of quassel-client if that's an option. ---------------------------------------------------------------------- CaptainMoistBeard · 2015-02-16 03:27 I applaud you for a detailed post. Just curious, why don't you run mIRC via WINE? ---------------------------------------------------------------------- i336_ · 2015-02-16 07:08 I just had a quick look at Quassel on a friend's machine via VNC; it definitely looks like it's matured since the last time I had a look at it (when it entered alpha, IIRC), and seems quite an compelling option. I probably should have initially covered this (and I've updated my post to include hardware info) - but I'm looking for something that will be *really, really responsive* on a slower CPU. Qt is... kind of big. I'll definitely consider Quassel, but I can't help feeling that it'll get sort of sluggish at times. If its client-server protocol didn't use the Qt data serialization routines (which are complex enough that the easiest way to support them is to simply pull in Qt) I'd definitely consider it because then I could pick between the Quassel client and a lighter client depending on context... but then I'd just be using a NIH reimplementation of ZNC. :/ ---------------------------------------------------------------------- i336_ · 2015-02-16 07:17 This post (and its detail level) actually exist because I've finally gotten over my "MUST WRITE OWN IRC CLIENT WITH SUPPORT FOR ALL MODELS OF KITCHEN SINK THAT HAVE EVER AND WILL EVER EXIST!!11eleventyfour!1" :D ^((That actually got out of hand. I accidentally designed a new kind of network-transparent event-based multi-paradigm cross-platform userspace application framework. >_>)) Running HydraIRC over WINE was actually one of my first instincts. However, such a setup definitely would not have supported the concept of detaching. In fact, when I switched to Linux I set it up on a server box as well as my desktop, and SSH'd from the desktop to Irssi running on the server. That was how I IRCed to begin with. I *could* configure something involving VNC (and in fact I'm typing this via VNC right now)... and it's a testament to the amazingness of the Internet that I'm typing in literally-realtime over a 16000km extension cable ^(**(:P)**), but, again, as I mentioned in my post... bandwidth issues :( ---------------------------------------------------------------------- Paradox · 2015-02-16 09:20 You can solve the lag issue with [mosh](https://mosh.mit.edu/) I used it over horribly laggy 3G to irc for a whole summer. It works great ---------------------------------------------------------------------- i336_ · 2015-02-16 09:32 Ah, thanks! I've actually tried Mosh, and found that while it does make truly horribly laggy links *much* more usable... 1. I can't really get my head around the aesthetics of the constantly- moving underline as what I type is acknowledged by the server. I hope mosh allows for color manipulation (perhaps it might take advantage of 256- or true-color terminal support) soon, because the idea is sound, I just can't handle the harshness of "the underline effect" as it's currently implemented. 2. On my system at least, Mosh seems to have internal terminal update delays that are fractionally higher than the raw link speed of plain SSH and VNC to the remote hosts in question. In other words, Mosh is actually *slower* for me than not-Mosh, not because it's a bad program, but because my link is actually fast enough (from my link's perspective, I have 800KB/s⇣/80KB/s⇡ to the machine I'm typing this post on via VNC right now). ---------------------------------------------------------------------- beleuchtung · 2015-02-16 18:41 > Just curious, why don't you run mIRC via WINE? Why would anyone do that? There are good IRC clients available for all platforms Wine runs on. If someone wants something similar to mIRC they can use KVIrc for example. ---------------------------------------------------------------------- StillDeletingSpaces · 2015-03-05 12:36 Not parent. 1. That's a bit peculiar. You can turn off mosh's predictive behavior, if you like, with `--predict=never`. 2. Regarding internal terminal update delays, that's also peculiar. If I had to guess, it'd be because of the CPU. I've not encountered slower experiences with mosh yet (experiences ranging from <10m 1Gbps links to 9000km inter-continentel links). I'm going to make a reply to your main post, but here's a question: If you have the bandwidth you're talking about... is bandwidth really an issue? ---------------------------------------------------------------------- StillDeletingSpaces · 2015-03-05 13:24 Your overall plan seems reasonable. I do have a couple things to add that you may want to consider. --- Regarding the smaller-font global window: Does the global window need to be attached. If you're open to HexChat-- you could use that to chat while using another client (like WeeChat) for the global window. If you like WeeChat (Note, I'm a recent convert), you could even configure a seccond Weechat instance for the global window (either connecting to the remote, a local relay/bouncer, or providing a local relay/bouncer for the client). It is a bit more overhead than just text-only console, but it gives you quite a bit of flexibility for a lot less work (e.g: chose which buffers to watch, smart filtering, multiple windows, and even buffer zooming). ---- Regarding playback with bouncer/times: ZNC and Weechat (which can be used as a bouncer/relay) say they support server-time. So with the proper setup you shouldn't need to hae to update the scripts. There is already a weechat script available to help with times if the bouncer doesn't support server-time. Weechat's remote client ability is fairly useful-- so if you wanted to, you can run one remotey and one locally-- it even supports the [message limits](http://dev.weechat.org/post/2012/12/24/Backlog-for- irc-protocol-in-relay) regarding the backlog-- so you wouldn't have to implement it yourself. You could connect remotely when you need, but use the local one as your main client (so you don't need to keep it open-- potentially wasting bandwidth updating your non-mosh screen) ---- tl;dr You can save bandwidth, have proper backlogging, and a *seperate* global client/window with only Weechat, if you really want to. Get the best of all of the worlds? ---------------------------------------------------------------------- i336_ · 2015-03-05 17:40 Thanks for your input! 1. I might give that a serious go at some point, thanks. 2. It might indeed be the CPU, although that's a bit perplexing as although the mosh client loader is a Perl script, the Mosh client itself (which handles all I/O, IIRC) is written in C. Right now, I have a moderate but nice amount of speed, but a very small monthly cap, although that's happily about to change. Remote SSH is not entirely out of the question, and might end up as part of my ultimate solution. ---------------------------------------------------------------------- i336_ · 2015-03-05 18:12 Thanks for noticing this thread! :) I'm actually still in the "\**headscratch*\*" phase with IRC while I continue finishing up on other projects first, so your input is and appreciated (and serendipitously well-timed!). --- I've tried HexChat and I don't mind it as a client, but on Linux it uses GTK2+, which is fast enough to not be arguably *unusable*, but slow enough to be irritating and get under my skin. As such, I've kind of blacklisted GTK2 on all my systems until I fix it (it's on my todo list of things to fix); I may end up giving HexChat a look then. By the way, what were you referring to with > If you like WeeChat, *[...]* It is a bit more overhead than just text-only console, but it gives you quite a bit of flexibility for a lot less work (e.g: chose which buffers to watch, smart filtering, multiple windows, and even buffer zooming). ? HexChat or Weechat? You referenced Weechat, but then said "more overhead than just text-only console". Were you referring to HexChat running the background? I hope so, because the features you mentioned sound awesome, and I don't want to run HexChat... :P --- Reading your post inspired one possible solution to the font issue: I actually intend to do a bit of figuring-out and come up with a set of scripts that give me commands like `/d` that detach/duplicate the current window into a new remote Weechat instance in a new terminal. I might extend this so I can do the same with the global buffer, and pick whether I want it as a split view in my main Weechat window, a detached new window, or off. I might also experiment with anchoring the global log to my root window (:D), and taking advantage of the various other random screens I have around here (I just got a dualhead-capable graphics card for my main box, and I'm also messing around with a spare PC at the moment). --- I had absolutely no idea Weechat had solved the message-timing issue, thank you so much for that input. I'll definitely be starting with poking that and seeing how it works, instead of trying to attack solving it myself. (On that note, I should probably take some time to think through how the other features I have in mind would be solved, and see if *those* solutions have already been implemented too, heh.) And am I to understand that mosh saves bandwidth? O.o wow...