I’m all about adding to the proverbial arsenal. 🤘

You’re absolutely right! I’d point you back to my notion of cost-benefit analysis. Anything more than the 20min that I’ve spent on analysis so far isn’t worth my time. If the VM falls over permanently, that was a risk and my time savings has already been worth that risk. If I were looking at something like a production file server or domain controller, sure – I’d spend more time on it. Likely though, I’d just have engineered it better in the first place. Not every problem warrants a high precision solution. 🙂

I’d be interested in seeing that, or at least knowing which ejabberd container you chose and why.

UPDATE: For anyone who comes back to this, or any new readers – I have added a MUC (chat room) on my XMPP server for discussion of any tech-related things, akin to the subject-matter of this blog. Hope to see you there!

xmpp:roguesecurity@groups.hackofalltrades.org?join

This is also a great article! Thanks for the link.

One cool point in favor of XMPP is that in a public setting (MUCs), there’s community. Moparisbest is an active participant in several of the MUCs that I’m in. Very cool!

This is great, I have not seen this post before. Thank you for sharing.

You make an excellent point here, that the burden of security and privacy is put on the user, and that means that the other party in which you’re engaged in conversation with can mess it up for the both of you. It’s far from perfect, absolutely. Ideally you can educate those that are willing to chat with you on XMPP and kill two birds with one stone, good E2EE, and security and privacy training for a friend. XMPP doesn’t tick the same box as Signal though, certainly. I still rely heavily on Signal, but that data resides on and transits a lot of things that I don’t control. There’s a time and a place for concerns with both, but I wanted to share my strategy for an internal chat server that also meets some of those privacy and security wickets.