New post: Chatting in the 21st century
This commit is contained in:
parent
07e0c498bf
commit
3dc462fc6b
GPG key ID:
D0EB762865FC5E36
2 changed files with 310 additions and 0 deletions
|
|
@ -1,5 +1,156 @@
|
|||
#+hugo_base_dir: ../
|
||||
|
||||
* DONE Chatting in the 21st century :debian:english:selfhost:free_software:matrix:irc:
|
||||
CLOSED: [2024-09-07 Sat 17:25]
|
||||
:PROPERTIES:
|
||||
:EXPORT_FILE_NAME: chatting-21st-century
|
||||
:END:
|
||||
|
||||
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
|
||||
|
||||
I chose to use [[https://matrix.org][Matrix]] as the place where I integrate everything.
|
||||
Despite there being some [[https://anarc.at/blog/2022-06-17-matrix-notes/][heavy (and justified) criticism]] 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 [[https://xmpp.org/][XMPP]] 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
|
||||
|
||||
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:
|
||||
[[https://github.com/spantaleev/matrix-docker-ansible-deploy][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
|
||||
[[https://github.com/element-hq/synapse][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)
|
||||
|
||||
There are [[https://matrix.org/ecosystem/clients/][a lot of 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
|
||||
[[https://github.com/alphapapa/ement.el][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 [[https://github.com/matrix-org/pantalaimon/][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 [[https://app.element.io/][Element]] 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 [[https://github.com/ajbura/cinny][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
|
||||
[[https://github.com/tulir/gomuks][gomuks]] or [[https://iamb.chat/][iamb]].
|
||||
|
||||
** Problem #2: IRC bridging
|
||||
|
||||
There are basically two types of IRC bridges for Matrix:
|
||||
|
||||
- The regular and most used [[https://github.com/matrix-org/matrix-appservice-irc][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 [[https://matrix.org][matrix.org]] and other big
|
||||
homeservers (including [[https://matrix.debian.social][matrix.debian.social]]) use. It's a complex
|
||||
service which allows thousands of Matrix users to connect to IRC
|
||||
networks, but that unfortunately [[https://libera.chat/news/matrix-bridge-disabled-retrospective][has complex problems]] and is only
|
||||
worth using if you intend to host a community server.
|
||||
|
||||
- A bouncer-like bridge called [[https://github.com/hifi/heisenbridge][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 much 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 [[https://wiki.znc.in/ZNC][ZNC bouncer]], 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
|
||||
|
||||
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 [[https://github.com/mautrix/telegram][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
|
||||
|
||||
Something else I wanted to be able to do was to receive notifications
|
||||
regarding new issues, merge requests and other activities from [[https://salsa.debian.org][Salsa]].
|
||||
For this, I'm using [[https://github.com/maubot/maubot][maubot]], which is awesome and has a
|
||||
[[https://plugins.mau.bot/][huge list of plugins]]. I'm using the [[https://github.com/maubot/gitlab][gitlab]] one.
|
||||
|
||||
** 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!
|
||||
|
||||
* DONE The Pagure Debian package is now orphan :debian:free_software:english:pagure:
|
||||
CLOSED: [2024-06-12 Wed 21:16]
|
||||
:PROPERTIES:
|
||||
|
|
|
|||
159
content/posts/chatting-21st-century.md
Normal file
159
content/posts/chatting-21st-century.md
Normal file
|
|
@ -0,0 +1,159 @@
|
|||
+++
|
||||
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 much 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!
|
||||
Loading…
Reference in a new issue