Es gibt keine größere Illusion als die Meinung,
Sprache sei ein Mittel der Kommunikation zwischen Menschen.
(Elias Canetti)

Dieser Inhalt wird in Deutschland nicht angezeigt. Weitere Informationen I use instant messaging a lot, since many years, and had a lot of different software running, with its own genuine problems and advantages.

In the beginning, it was the time when ICQ became popular, and I used the official ICQ client under Windows 98. It made typewriter sounds on every character that one typed. It was the first software I can remember that did not exit on close, but minimized to tray by default.

However, it had a lot of eyecandy, and needed a lot of my 64 MB RAM, and crashed often. So, at some point, I switched to Miranda IM, which was much better. At that time I got to know IRC, and joined a few IRC channels through Miranda IM. I only had a dial-up connection, which probably had some package loss and a high latency, so it was often the case that Miranda IM warned me that some message could not be sent. When "retrying" to send the message, it sometimes arrived multiple times.

At some point I switched to Linux. At that time, it was not as easy as today to get a working ICQ Client under Linux. So in the beginning, I used ICQ2GO which is now called Web-ICQ. Nowadays, it uses JavaScript. But at that time, it used a Java Applet - which also swallowed a lot of RAM and did not have the Quality under Linux that it has today, and also crashed often. This became even worse when they ported it to Macromedia Flash, which really was a pain at that time (it still is a pain sometimes).

I do not know exactly in what order I used which clients after that. For a long time, I used SIM, but for some reason I did not keep using it, not sure why, probably there was a lack of compatibility with a linux distro I wanted to use (since other software sucks too).

Kopete used to be the standard messenger under KDE, and I liked it, but at that time, it had one problem: Others received my messages, but sometimes, their messages did not arrive. I still have no idea why, and I am not really interested, but they apparently fixed it. Then there was GAIM, which was later renamed into Pidgin. It has a lot of flaws, but sort of works. Furthermore, at that time I started using Jabber, and sooner or later arrived at Psi, which is a pure XMPP client, but supports transports. But the transports … sucked.

At some point, I discovered BitlBee. And used it with Irssi. From that point, I mostly used either Pidgin or BitlBee. When I started studying, it was the first time when I really had the problem of syncing many computers. Mostly I used Pidgin on every computer, and synced the directories - this was not perfect, but sufficient.

And there we almost come to the current setup: A central server with a tmux session. I tried Centericq and Finch, but they did not convince me, so I preferred BitlBee and Irssi. Though, I missed notifications via libnotify, which are sent by some other clients.

We are now approaching the part where I try to "fix" software problems myself. Of course, Irssi is scriptable, and there is a setting to let it execute a command when receiving messages. But instead, I wanted a more general solution for other purposes. So I thought it might be possible to tell some terminal emulator to execute a command, when a BEL character arrives. Apparently, such a terminal emulator does not exist, so I experimented with terminal stuff myself. I found the forkpty(3) function, and I am able to write such a piece of software now, but I lost interest.

In the meantime, I began using mobile internet, which … sucks in some places, so it happens that connections get lost. Directly using Pidgin and other clients, message loss occurs, but running BitlBee on a server with a good connection works well, and thanks to the tmux session, I can always reconnect a broken ssh connection. But as reconnecting gets on my nerves, I switched to mosh. So until I got a smartphone, my instant messenger software stack consisted of bitlbee behind irssi behind tmux behind mosh. Yes, that sounds complicated, but one fundamental principle of Unix is todo one thing and do it right, and every part of this software stack does its job pretty well - at least on personal computers.

On my small smartphone, it is a pain to use terminal applications. There is the Hacker's Keyboard, which I use, but which does not show the relevant keys in portrait mode, and makes the terminal half as big while typing, even in its experimental transparent mode. There is an app called Transparent Keyboard, which really is a transparent overlay keyboard, but the keys are too small on my screen, so this is not an option for me. Both keyboards are probably very useful on large displays, but on my display, this is unusable.

In my opinion, terminal applications have a completely different UI model than most other apps on Android. They usually focus on the keyboard, while smartphone UIs focus on the touchpad. So it is legit not to use the system's input method, but having an own one. I would suggest a semi-transparent overlay keyboard over the whole terminal: Most terminal applications do not support mouse input, so there is never a reason to actually touch the terminal window itself. On the other hand, relevant information is shown in most of the text window, so it is desirable that this text window uses most of the screen. So I guess this is reasonable.

So recently, I am using Quassel. It has several advantages over IRC bouncers like bip, and fits my needs comparably good. But it also has some problems. One thing is that currently, the Android client does not do compression. A workaround that works fine for me so far is to turn off SSL encryption in Quassel, and tunnel the traffic through a compressing ssh connection, which I generate with ConnectBot. ConnectBot is also not completely flawless: In some configuration it always needed huge amounts of processing power, thus lowering my battery, which is why I do not touch the current settings at all. And well, it hangs up occasionally, and sometimes Quassel refuses to connect to the forwarded port for no apparent reason. And it still takes ages to connect, even though I set the backlog length to 1 already. Quassel seems to always send, besides its whole core configuration, all messages that arrive in all channels you joined. However, on a mobile internet connection, I want traffic to be reduced as much as possible. It would be nice if only state changes ("highlighted", "unread messages", etc.) of channels in which I only idle around were sent, and the messages are only loaded on demand. The usual behaviour of IRC chatters is to idle in a lot of channels and only occasionally look into them.

Besides that, I recently began to join some XMPP Groupchats, which does not really work properly in BitlBee, at least in my version. It has problems with unicode nicknames, and does not restore these chats after I log out of a session. However, I have workarounds for this, and on the whole, BitlBee works well for me. But it is still an IRC gateway to different chat systems, which inherently comes with some compatibility problems, one of them being the fact that IRC messages cannot contain line breaks, while most IM protocols allow this. Especially when pasting text, the other side gets the text chunked into its lines, and this is really annoying. The solution it provides is the paste_buffer and paste_buffer_delay setting, in which you can set a time in Milliseconds that indicates when two consecutive IRC messages are packed into one single IM message. So when you paste a long text into your IRC client, and it sends them sufficiently fast, this is a good approximation … except that Quassel will not let you send pasted text reasonably fast, due to a "feature" called "flood control", which apparently cannot be turned off. This is a desirable feature on public networks and channels, in the sense that it protects you from accidentally flooding. Well, it does not really protect you, it apparently just delays the messages a bit, which is - in my opinion - even worse than just sending them directly. It forces without warning. Irssi asks you for an affirmation when it notices that a lot of messages are typed in at once, if I remember correctly, one has to confirm with Ctrl-D. It warns without forcing. That is an important rule, I shall call it Uxul's 5th rule:

Good software warns without forcing. Bad software forces without warning.

However, both pieces of software have their unique advantages and disadvantages.

In the end, one question remains: What to do about it? While my current setup works fine for the moment, it is not satisfactory on the long term. So let me discuss a few alternatives I or other people came up with:

Buy a new phone

I will probably buy a new phone with a larger display sooner or later, and thus solve some of the problems. But I do not consider solutions of the form "throw hardware on your problems" as good. I am pretty sure that I will run into other software problems with a new phone.

Irssi ConnectBot

There is a fork of ConnectBot, called Irssi ConnectBot, which I would probably use on the aforementioned hypothetical new phone. However, it makes use of input buttons my phone does not have, and it uses swiping, and I hate swiping and gestures in general, because they often fail when you have stubby fingers. Furthermore, it confuses my configuration of ConnectBot, when installed parallely.

Writing or patching an existing terminal emulator…

…in the way I described above might be worthwile even for other applications, but both getting an own implementation stable and understanding another implementation are a pain and take long. This is probably a nice project for it own sake, but not for this specific problem.

Irssi-Proxy with bouncer

There is an Irssi extension called irssi-proxy, where Irssi exposes its connections, so a second client can access them. Then I could just run a bouncer on these exposed connections so I get the backlog. However,

Writing an own new IRC Client

Years ago I programmed an IRC Bot with Java, using TCP sockets, but implementing the IRC protocol myself. It is a comparably simple protocol. A suspendable web-based client would be perfect, as it could be made accessible on both PCs and phones with little effort. I considered using Common Lisp, Hunchentoot and cl-irc, and producing a simple web-based client should be very easy. On the other hand, it would produce one more piece of software that is poorly maintained and has its own unique flaws, without really adding any value. The better alternative would be …

Writing a Web-Frontend for Quassel

The advantage of Quassel is that it already has a lot of infrastructure for distribution of configuration settings and their meanings. And once running, there might be enough interest to keep such a project alive, even in times when I can not actively do so.

Writing a Web-Frontend for Irssi

Irssi is scriptable. There already exists a frontend for it, but it looks anachronitic (the link for the current development seems to be dead). However, the Irssi-API looks nice, signal-based, sufficiently nice to make such a project possible.

Writing a purple-based Web-Client

…and probably failing like the many people before. But it might be worthwile for its own sake, as an exercise to learn libpurple, and knowing an advanced multi-protocol chat library might be an advantage in many ways. There is this nice introduction to libpurple. Of course, I am not the first one with that idea, there is at least WebPidginZ which I did not try yet due to the lack of time. Furthermore, there is the Broadway Backend for GTK, so maybe Pidgin will run on it.

Just wait and use workarounds until somebody else does the work

This is the most probable thing I will do. And probably also the most probable thing most other people do. And therefore, probably the reason for all of that mess.