Why I choose not to use WhatsApp, Viber et al

There are many messenger apps these days that have very similar features, and are widely used. I’d usually describe them as “modern” messengers. I choose not to use them. I sometimes get into discussions about why. I’ll update this post if I get new perspectives or if I find better ways to clarify my opinions.

Here are some anti-features from my perspective, widely (but not universally shared), that make me strongly prefer not using these messengers:

  • Uploading all contacts. Many modern messengers use your phone’s addressbook as the primary source for the contact list. This is, in principle, laudable. One source of contacts is a good idea1.

    However, to enable the distinction between contacts that do not use this messenger and those that do, the clients have opted to query their servers for this piece of information. To do so, they upload all your contacts, and see whether the phone number is connected to the service or not.

    Despite not having a signal of whether a contact is ‘weak’ or ‘strong’ (occasional and mainly formal interactions vs daily friendly interactions), messengers can use this to form social graphs. I don’t have a reason to believe they are doing this or exploiting this information, however, I’d prefer a smaller number of companies to have access to my contact list. I’m sure my contacts would prefer that as well.

    For this reason, I’ve chosen that the primary company that’ll have access to this is the one that already syncs my contacts and sees all my email: Google. This means I get restricted to Hangouts (which is mid-way between ‘classical’ and ‘modern’ messengers) or Allo (which is slick, but underused, and has other flaws from this list).

    • Workaround: Messengers, please let me choose not to upload all contacts. Please don’t tell me I cannot block iOS and Android from you grabbing all my contacts. Please let me share only some contacts with you, or manually enter the phone number I want to reach out to.
  • Phone numbers only, please. I use many devices. Counting off the top of my head, I use 82 ‘smart’ devices regularly and 43 sporadically. This is not counting all the operating systems I have on them: both my desktop and my old laptop have 3. How about browsers? Anything with OS X has at least Safari and Chrome.

    I change environments multiple times a day. I’ve changed countries. I could change my phone number. It’s not unreasonable that I expect my conversation to continue from one environment to the other. If I’m on my desktop, I strongly prefer not to have to take out my phone just to see that Jack has said “hi” without any other followup. And doing this while I’m dealing with a page or writing or updating a very convoluted test is very distracting. It could be an important message — should I really have to decide between 15s to get the phone and see the “hi”, making me distracted for the next 5-10min, or leaving a possibly important message unseen?

    Tying a messenger to one phone number and thus one device is ridiculous.

    • Non-workaround: Browser-based solutions. I could receive and send messages from my desktop — hurray? While I do want a web-based client to be available when I’m on a Chromebook, due to e2e they’re usually convoluted and require messages to go through your phone, only to go back through the provider’s servers (presumably re-encrypted) and to be presented in a web UI. I object to this convoluted solution on moral grounds. 🙂

      I also don’t expect I get to integrate with my desktop environment that well.

    • Non-workaround: Wearable devices. While I can see the messages quickly, I have to actually own one. My Moto 360 broke down long time ago, and I’m still waiting for a decent, affordable Android Wear 2.0 device to become available in Ireland. (If I need to get a new one, why not get a proper upgrade?)

    • Counter-example: iMessage. Yep, in place of a workaround, I’m giving a specific “modern messenger” solution. I can not only tie multiple phone numbers, but also multiple email addresses, all on multiple devices, to the same account. Messages.app (formerly iChat), an OS X feature which integrates with iMessage, is a desktop, non-browser solution that neatly integrates with the OS as well.

      I would use this messenger much more if iMessage was available on non-Apple devices and on the web.

  • Ubiquitous e2e. In principle, I like encryption. It does come with huge costs. Most messengers that implement it (well) become terrible with syncing message archives, and become terrible storing them for prolonged periods of time.

    They also have to decide where to store the keys. To keep the whole contraption secure, they often choose a storage mechanism that makes it hard to exfiltrate the keys. This is a good thing — except it prevents sync from working, and it makes it hard to introduce new devices (or browsers!) into the mix. And as I said, I use many, many devices.

    Situations where I actually, genuinely care about e2e enough to break message sync, message archiving, and make provisioning new devices for the same account difficult or impossible — those situations are very rare. I can think of maybe 5-10 cases over the past 3 years, and I can’t even recall the specifics. Cases where I wanted to find details of an old conversation, or where I wanted to continue an old discussion, those are far more frequent.

    • Counter-example: iMessage as a service is doing somewhat well here again. I am just guessing, but it seems like, once provisioned, a message will be encrypted for a particular device’s key in addition to all other devices. If a device is under-used, the key gets phased out. Messages get synced while a device is provisioned.

      Where it’s not doing so well is in-browser support. Apple recently introduced Business Chat and iCloud syncing for messages. It seems to let third-party providers create integrations with iMessage, including web based. It’s for businesses only, from what I can tell!

    • Counter-example: What about, say, WhatsApp’s web UI? Link to your phone, and have all messages go through it; a secure solution, but which I object to morally. I was going to say “I have no idea how message sync interacts with e2e with WhatsApp”, but for me it would be a non-problem with WhatsApp, as either I’d use web UI (which would presumably fetch messages from the phone), or I would not have message sync (as only one phone has a particular phone number). Possibly the key and messages get backed up to Google Drive on Android, but that solves the problem of “I’m changing the phone”, not “I’m using multiple phone numbers and non-phone devices concurrently”.

    • Workaround: What I’d really like to see happen is optional e2e. At the very least, let users agree not to e2e, and reap the benefits of message sync, nice and slick web UI, easier provisioning of new devices. When I use XMPP, I don’t bother at all turning on OTR, OMEMO, or OpenGPG (mechanisms supported in Conversations, top of the line messenger for Android) — but I strongly care about support for Message Carbons (“deliver messages to all online clients”) and Message Archive Management (“archive messages on the server and let clients request the archive”). I own my domain, so I get the benefit of not being tied to a single provider. Friends who use my secondary domain are also welcome to request archive export should they choose to spin up their own server — I’ll gladly spend the time providing them this data. (I’ll also delete the data from their archives on my server, as well, but otherwise I’d expect that I can keep my own records of these chats.)

I could also simply not worry about these problems.

For example, my personal social graph is not going to be important or even a useful source of information to sell me things4. That said, I don’t know what all the contacts in my addressbook are up to. Do I want everyone to tie me to them? It probably does not matter, but I choose to draw the line there.

I could also choose to use the messengers only on one device, and ignore notifications that come while I am focused. I could choose to accept e2e and all the downsides it brings to the sync table. I could choose to use iMessage with my Apple-toting buddies (hint: there aren’t many!). I could choose to install Facebook Messenger, tolerate battery drain, and tolerate having an additional company have access to my communications.

All that said… I don’t get that many benefits from any of these messengers. I can easily reach people I care with XMPP, Hangouts or even SMS. If SMS fails, I can, occasionally, even reactivate the Facebook account and reach out to people using Facebook Messenger on the desktop. I don’t have a good reason to compromise, or to figure out a workaround such as setting up an XMPP transport for WhatsApp. People who happen to be using WhatsApp — I can reach them through SMS as well, and often through Hangouts as well.

  1. Android allowed the apps to do it the other way around, too; applications should integrate with the Contacts app. In practice, social network apps, even if they integrated with Android’s contacts, chose to remove the integration many years ago. This is disappointing. 
  2. Phones: Nexus 6P (personal), iPhone 7 (work). Tablets: iPad Air (personal). Computers: desktop, Macbook Pro 2016, Digital Ocean VPS (personal), workstation, HP Chromebook (work). Other: Nvidia Shield Android TV, Samsung 6400 TV, QNAP TS-509 NAS w/ debian (personal). 
  3. Phones: Nexus 5, Jolla (personal). Tablets: original iPad w/ iOS 5.1.1 (personal), Nexus 7 (work). Computers: Macbook unibody late 2009, Chromebook (personal). 
  4. I mean, I rarely buy exactly the same product just because a friend has it. 

What are OSC terminal control sequences / escape codes?

Changelog for a recent release of SecureShell for Chrome
included a mention of “Support for iTerm2 OSC-9 growl notifications”. This is displayed in terminal when you’re SSHing into a machine, and this entry piqued my interest.

Turns out it’s from hterm’s changelog. And turns out hterm has a nice list of supported control sequences.

OSC are “operating system command” control sequences and there’s a few of them supported by hterm / SecureShell. I find a few super interesting (\033 being ESC in the doc linked above):

  • 0: set window title: echo -e "\033]0;This is the window title\a"
  • 9: show system notification (iTerm2 variant): echo -e "\033]9;This is the notification text\a"
  • 777: show system notification (rxvt-unicode / urxvt variant): echo -e "\033]777;notify;This is the notification title;This is the notification text\a"
  • 52: clipboard operation; hterm only supports c for copy: echo -e "\033]52;c;$(base64 <<< hello)\a"

I bought a Samsung UE49KU6400

People ask me where I bought my TV. I got it at DID Electrical on Malahide Road for EUR699. I’m very happy with DID’s price and service; another store where I looked at this TV had it for EUR849. I got extended warranty for EUR99, but then I got a EUR20 voucher for another purchase (spent on an aerial) and an additional EUR20 discount at manager’s discretion. Very, very pleasant experience.

Some thoughts and discoveries on the TV:

  • Samsung UE49KU6400(pricespy) can do 4K and HDR. Not much content that can do it, but Netflix in Ireland has a few pieces of content: things like House of Cards are 4K, and Marco Polo is HDR.
  • Builtin Tizen OS is useless. Builtin Netflix app doesn’t say anything about supporting HDR, so I assume it doesn’t. I am very happy that I have nVidia SHIELD. Switching between TV and an app is harder and lossier than switching to external HDMI.
  • Builtin Vimeo app is semibroken, and Android TV version of Vimeo seemingly does not exist.
  • nVidia SHIELD can be used to send Marco Polo in HDR.
  • nVidia GPUs before Maxwell and Pascal architecture (e.g. my GTX 770) can’t output HDR.
  • Quite happy with upscaling. Frame interpolation, presumably up to 60fps, can be turned off but is a pretty nice parlor trick.
  • PIP only works when you have the TV tuner set up, and when you switch to an external input (e.g. HDMI). Switch to HDMI, and then you can watch TV in a small window. Useful only if you want to watch YouTube videos while ads play on TV.
  • Upscaling from full HD and below works fine with neat results.
  • Image can be made quite bright and exciting-looking. It looks like you’d want to switch to Dynamic image type to get the in-store experience. Probably bad for eyes though.
  • There’s sports mode. It makes image brighter. It’s got a dedicated button on the remote, which causes very annoying noise and animation to appear when sports mode is entered AND left.
  • There is a gaming mode, presumably cutting down on latency. I didn’t try to notice a difference.
  • There is a second remote called “Smart Remote”. There’s way less buttons than on the main remote. It tries to be similar to Apple TV or SHIELD remote. Rather useless.
  • To get HDR from HDMI, you have to turn on the relevant option (“UHD Color”). Not sure why that’s not the default.
  • 4K/UHD HDR is barely noticable, but nice.
  • It seems that “UHD Color” (HDR) is only available on one of the inputs. I’m not sure, but it didn’t look like it could be turned on on another HDMI input after I flipped it on on HDMI1. Not that I have another HDR-capable device; this involved re-plugging SHIELD into HDMI2.

Overall I’m happy.

Changing the default file manager away from Nautilus

Nautilus is opening the desktop, making the experience miserable under i3 when all you’re trying to do is ‘view files in directory’.

XFCE’s Thunar is lightweight, and it doesn’t try to create a desktop window.

To get apps such as Chrome to handle “open directory” commands using Thunar, teach xdg-mime about it:

$ sudo apt-get install thunar
$ xdg-mime query default inode/directory
$ xdg-mime default Thunar.desktop inode/directory  # yep, Thunar's desktop file is titlecased on Debian-derived systems
$ xdg-mime query default inode/directory
$ xdg-open .
...thunar opens...

This is sort-of a follow-up to my previous post on this topic. See also, Debian’s article about usage of MIME types.

But my dog does.

Migrating Prosody from text store and sqlite3 to PostgreSQL


  • You started off from the basic storage config:
    • Regular data is in filesystem.
    • mam (xep0313) message archive is in SQLite3.
  • You want to transition to using just PostgreSQL.
  • PostgreSQL version is 9.4.


# # largest version of pgsql you have
~# apt install postgresql-9.4-client

# # get lua-dbi module for pgsql
~# apt install lua-dbi-postgresql

Creating PostgreSQL user

# # PostgreSQL trusts users connecting over unix domain socket to be the
# # same as their local account.
# # Therefore, become postgres -- the admin account.
user:~$ sudo su postgres

# # run user creation
postgres:~$ createuser --interactive
# # name: prosody
# # no other administrative options

# # run postgresql client
postgres:~$ psql
-- create database

-- give the prosody user all rights on it
GRANT ALL ON DATABASE prosody TO prosody;

-- in case of connecting over network and using md5 trust,
-- set prosody account password:
ALTER ROLE prosody WITH ENCRYPTED PASSWORD 'here_some_password';

Over network?

Assuming you want to connect over the network, edit /etc/postgresql/9.4/main/pg_hba.conf. Append:

# type, database, user, address, auth method
host prosody prosody md5
  • Try to minimize your permitted netmask.
  • Can you configure a more secure auth method than md5? Do so.

Migrate data from filesystem

# # as prosody local user

prosody:$ cd prosody-hg/tools/migrator

# # overwrite the config.
prosody:$ cat > migrator.cfg.lua << _EOF
local data_path = "../../data";

input {
        type = "prosody_files";
        path = data_path;
output {
        type = "prosody_sql";
        driver = "PostgreSQL";
        database = "prosody";
        username = "prosody";
        password = "here_some_password";
        host = "database.host.here"; -- this assumes network connection; migration with local user credentials was not attempted.

# # run the migrator in ~/prosody-hg/tools/migrator
prosody:$ lua prosody-migrator.lua input output

Migrate mam archive from SQLite3

# # as prosody user

prosody:~$ cd prosody-hg/data

# # Having first verified there is nothing in Prosody table...
prosody:$ sqlite3 prosody.sqlite 'SELECT COUNT(*) FROM prosody;'
# # ...drop prosody table. All its data (roster etc) was until now stored on the filesystem.
prosody:$ sqlite3 prosody.sqlite 'DROP TABLE prosody;'

# # dump and massage the sqlite3 output, piping it into psql.
# # psql authenticates as the 'prosody' user and does not require the password.
prosody:$ sqlite3 prosody.sqlite .dump | \
    grep -v 'BEGIN TRANSACTION;' | \
    grep -v sqlite_sequence | \
    awk '/CREATE TABLE/{gsub("`","\"");} 1' | \
    awk '/CREATE UNIQUE INDEX/{gsub("`","\"");} 1' | \

# # manual step 🙁
# # fix the autoincrement.
prosody:$ sqlite3 prosody.sqlite 'SELECT COUNT(*) FROM prosodyarchive;'
# # use this number + 1 in:
prosody:$ echo 'ALTER SEQUENCE prosodyarchive_sort_id_seq RESTART WITH 123456;' | psql

Update Prosody config

In prosody.cfg.lua:

storage = {
        archive2 = "sql";
sql = { driver = "PostgreSQL", database = "prosody", username = "prosody", password = "here_some_password", host = "database.host.here" }

Getting sound and other panels in gnome-control-center outside GNOME

Missing some panels in gnome-control-center? No “Online Accounts”? No “Sound”?

Apparently, panels are defined through .desktop files in /usr/share/applications (!), and they mostly have the setting of OnlyShowIn=GNOME; or OnlyShowIn=GNOME;Unity;.

To trigger them appearing in, say, i3, xfce or similar, you need to pretend you’re actually running GNOME by exporting the XDG_CURRENT_DESKTOP variable with the value of GNOME.

XDG_CURRENT_DESKTOP=GNOME gnome-control-center