blog/content/posts/chatting-21st-century.md

+++
title = "Chatting in the 21st century"
author = ["Sergio Durigan Junior"]
date = 2024-09-07T17:25:00-04:00
tags = ["debian", "english", "selfhost", "free-software", "matrix", "irc"]
draft = false
+++

Several people have been asking me to explain and/or write about my
solution for chatting nowadays.  I realize that the current scenario
is much more complex than, say, 10 or 20 years ago.  Back then, this
post would probably be more about the IRC client I used than about
different chatting technologies.

I have also spent a non trivial amount of time setting things up the
way I want, so I understand that it's about time to write about my
setup not only because I think it can be helpful to others, but also
because I would like to document things for myself.


## The backbone: Matrix {#the-backbone-matrix}

I chose to use [Matrix](https://matrix.org) as the place where I integrate everything.
Despite there being some [heavy (and justified) criticism](https://anarc.at/blog/2022-06-17-matrix-notes/) on the
protocol itself, it serves me well for what I need right now.
Obviously, I don't like the fact that I have to provide Matrix and all
of its accompanying bridges a VPS with 4GB of RAM and 3 vCPUs, but I
think that that ship has sailed, unfortunately.

In an ideal world, I would be using [XMPP](https://xmpp.org/) and dedicating only a
fraction of the resources I'm using today to have a full chat system.
And since I have been running my personal XMPP server for more than a
decade now, I did try to find a solution that would allow me to keep
using it, but unfortunately the protocol became almost a hobbyist
thing, so there's that.


## A few disclaimers {#a-few-disclaimers}

I self-host everything, including my Matrix server.  Much of what I
did won't work if you don't self-host Matrix, so keep that in mind.

This won't be a post _teaching_ you how to deploy the services.  My
intention is to describe _what I use_ and for _what purpose_.

Also, as much as I try to use Debian packages for everything I do, I
opted to deploy all services using a community-maintained Ansible
playbook which is very well written and organized:
[matrix-docker-ansible-deploy](https://github.com/spantaleev/matrix-docker-ansible-deploy).

Last but not least, as I said above, you will likely need a machine
with a good amount of RAM, CPU and storage, especially if you deploy
[Synapse](https://github.com/element-hq/synapse) as your Matrix homeserver (which is what I recommend if you
plan to use the bridges I'll mention).  My current VPS has 4GB of RAM,
3 vCPUs and 80GB of storage (of which I'm currently using
approximately 55GB).


## Problem #1: my Matrix client(s) {#problem-1-my-matrix-client--s}

There are [a lot of clients](https://matrix.org/ecosystem/clients/) that can talk the Matrix protocol, but most
of them are either web clients or GUI programs.  I live on the
terminal, more specifically inside Emacs, so I settled for the amazing
[ement.el](https://github.com/alphapapa/ement.el) Emacs mode.  It works surprisingly well, but unfortunately
doesn't support end-to-end encryption out of the box; for that, you
have to hook it up with [pantalaimon](https://github.com/matrix-org/pantalaimon/).  Unfortunately, the project seems
abandoned and therefore I don't recommend you to use it.  I don't use
it myself.

When I have to reply some E2E encrypted message from another user, I
go to my web browser and use my self-hosted [Element](https://app.element.io/) client.  It's a
nuisance, but one that I'm willing to accept because of security
concerns.

If you're into web clients and don't want to use Element (because it
is heavy), you can try [Cinny](https://github.com/ajbura/cinny).  It's lightweight and supports a decent
set of features.

If you're a terminal lover but don't use Emacs, you may want to try
[gomuks](https://github.com/tulir/gomuks) or [iamb](https://iamb.chat/).


## Problem #2: IRC bridging {#problem-2-irc-bridging}

There are basically two types of IRC bridges for Matrix:

-   The regular and most used [matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc).  This bridge _takes
    Matrix to IRC_ (think of IRC users with the `[m]` suffix appended to
    their nicknames), and is what the [matrix.org](https://matrix.org) and other big
    homeservers (including [matrix.debian.social](https://matrix.debian.social)) use.  It's a complex
    service which allows thousands of Matrix users to connect to IRC
    networks, but that unfortunately [has complex problems](https://libera.chat/news/matrix-bridge-disabled-retrospective) and is only
    worth using if you intend to host a community server.

-   A bouncer-like bridge called [Heisenbridge](https://github.com/hifi/heisenbridge).  This is what I use
    personally.  It _takes IRC to Matrix_, which means that people on
    IRC will _not_ know that you're using Matrix.  This bridge is much
    simpler, and because it acts like a bouncer it's pretty much
    impossible for it to cause problems with the IRC network.

Due to the fact that I sometimes like to use other IRC clients, I
still run a regular [ZNC bouncer](https://wiki.znc.in/ZNC), and I use Heisenbridge to connect to
my ZNC.  This means that I can use, e.g., ERC inside Emacs _and_ my
Matrix bridge at the same time.  But you don't necessarily need to run
another bouncer; you can simply use Heisenbridge and connect directly
to the IRC network(s) you want.

A word of caution, though: unlike ZNC, Heisenbridge doesn't support
per-user configuration when you use it in bouncer mode.  This is the
reason why you need to self-host it, and why it's not possible to
offer the service to other users (they would have access to your IRC
network configuration otherwise).

It's also worth talking about logs.  I find that keeping logs of
everything that goes on IRC has saved me a bunch of times, and so I
find it really important to continue doing that.  Unfortunately,
neither `ement.el` nor Element support logging things out of the box
(at least not that I know).  This is also one of the reasons why I
still keep my ZNC around: I configure it to log everything.


## Problem #3: Telegram {#problem-3-telegram}

I don't use Telegram myself, but unfortunately several people from the
Debian community do, especially in Brazil.  There is a whole Debian
community on Telegram, and I wanted to be able to bridge our Debian
Matrix channels to their Telegram counterparts.

I am currently using [mautrix-telegram](https://github.com/mautrix/telegram) for that, and it's working
great.  You need someone with a Telegram account to configure their
credentials so that the bridge can connect to it, but afterwards it's
really easy to bridge channels together.


## Problem #4: GitLab webhooks {#problem-4-gitlab-webhooks}

Something else I wanted to be able to do was to receive notifications
regarding new issues, merge requests and other activities from [Salsa](https://salsa.debian.org).
For this, I'm using [maubot](https://github.com/maubot/maubot), which is awesome and has a
[huge list of plugins](https://plugins.mau.bot/).  I'm using the [gitlab](https://github.com/maubot/gitlab) one.


## Final thoughts {#final-thoughts}

Overall, I'm satisfied with the setup I have now.  It has certainly
taken some time and effort to find the right tool for each problem I
needed to solve, and I still feel like there are some rough edges to
soften (like the fact that my Emacs client doesn't support E2E
encryption out of the box, or the whole logging situation), but
otherwise things are working fine and I haven't had any big problems
with the deployment.  You do have to be much more careful about stuff
(for example, when I installed an unrelated service that "hijacked" my
Apache configuration and made Matrix's federation silently stop
working), though.

If you have more specific questions about any part of my setup, shoot
me an email and I'll do my best to help.

Happy chatting!