mash-playbook VS nimb

Sometimes the easiest and quickest way to try (or even deploy) a new service is by using the recommended docker-compose-setup that they often have as an example. But if you have an existing infrastructure, like we do with the great mother of all self-hosting ansible playbooks, this isn't always easy to integrate. In particular when that infrastructure is managed and started and stopped independently from the additional docker-compose you intend to add. Lucky, who is running their out-most proxy using traefik, because with just a few extra labels your docker-compose becomes available TLS-certs included.

Yes! And don't forget MASH [0], its a collection of Ansible roles that is compatible with the Matrix Docker Ansible Deploy playbook. In case you want to add more services to your Matrix server.

[0]: https://github.com/mother-of-all-self-hosting/mash-playbook

This is why I like https://github.com/mother-of-all-self-hosting/mash-playbook and its associated Ansible roles for configuring various services.

All the portability of Docker, plus (something close to) the ease of use of installing a distro package like an .rpm or .deb.

I use Authentik. Is speaks LADP, OICD, OAUTH and SAML so most use cases are already included. For everything else there is the option of using a proxy provider with an appropriate webserver that uses [Forward aut](https://doc.traefik.io/traefik/middlewares/http/forwardauth/). I never used Forward Auth but the general setup is discussed here: https://github.com/mother-of-all-self-hosting/mash-playbook/issues/50

more here

Your security advisory has been quite helpful and I could reproduce the issue involving CR. It is particularly enlightening to know that the null byte could also cause the same issue because some IRC servers may interpret the null byte too as a line ending.

It is late here but I have pushed a quick fix to plug this loophole: <https://github.com/susam/nimb/commit/c5d6c4c>. Review comments, feedback, pull requests, patches, etc. are very welcome! This comment thread has been productive and constructive. Thank you!

Review comments, pull requests, feedback, etc. are welcome. T

I have had my own share of problems with both portalled rooms as well as plumbed rooms on Matrix. Dropped messages, dropped connections, etc. Sometimes the re-connection times can be several hours long. Despite these problems, the portalled rooms have been a convenient way for many IRC beginners to quickly set up a relatively persistent connection to the IRC network via the Matrix bridge. That convenience is now going to be lost unless the IRC channel operators opt-in to set up a plumbed room on Matrix and sufficiently advertise the plumbed rooms.

As a channel moderator, I haven't been too happy with the plumbed channels either. For example, one of the things I have found to be a little problematic is that the Matrix bridge service joins the Matrix room with Admin power level. To avoid these complications, I wrote my own tiny script to bridge the Matrix rooms and IRC channels I needed. Since my script joins the networks as regular clients, it does not need elevated privileges in the channels/rooms. In case, anyone is interested in the script, I have it available here: https://github.com/susam/nimb

The section "Differences from Matrix Appservice" at the bottom of the README in the preceding link explains some of the inconveniences I faced with the Matrix bridge service for plumbed channels and why I had to write my own script to avoid them.