From 3dc462fc6baec11e4878e5b10ee4199f979c6f9b Mon Sep 17 00:00:00 2001 From: Sergio Durigan Junior Date: Sat, 7 Sep 2024 17:26:10 -0400 Subject: [PATCH] New post: Chatting in the 21st century --- content-org/all-posts.org | 151 +++++++++++++++++++++++ content/posts/chatting-21st-century.md | 159 +++++++++++++++++++++++++ 2 files changed, 310 insertions(+) create mode 100644 content/posts/chatting-21st-century.md diff --git a/content-org/all-posts.org b/content-org/all-posts.org index 3ab8b3f..fc6d6ec 100644 --- a/content-org/all-posts.org +++ b/content-org/all-posts.org @@ -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: diff --git a/content/posts/chatting-21st-century.md b/content/posts/chatting-21st-century.md new file mode 100644 index 0000000..e1e2544 --- /dev/null +++ b/content/posts/chatting-21st-century.md @@ -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!