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!
post
When I see E2EE and XMPP mentioned, I think of this blog post by Soatok, outlining some very odd cryptographic choices in XMPP + OMEMO: https://soatok.blog/2024/08/04/against-xmppomemo/
I would very much like to see a richer playing field than just Signal for private messaging, but it's a tough nut to crack. For exactly which aspect that turns me away from XMPP for E2EE, I think this nails it down:
you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).
When the competition is Signal, these sorts of details matter a lot.
This is great as last time I looked to set up prosody there were no official container images.
I just need to figure out how to set up slidge/matrix bridge and then I can ditch my matrix server.
Yeah they just redid their container image pipeline and these containers are the result!
This is so nice to hear.
Agreed! Runtime environment management is so much nicer with modern containerization. You or ally can't overstate how much better it is to have app stack state be entirely divorced from OS state. I'm very pleased they're back on the bandwagon as well.
Stand up a server and come join our MUC!
This week I was setting up an IRC server for a group of friends, but might switch it to XMPP. I also have a v good friend who is hosting a XMPP server that sees very little use and has some good lots of legacy stuff going on, I'll try to ping them to see if it's worth to spin something completely new.
Prosody is a great piece of software, and so is ejabberd which offers some perks. I can't speak for the other servers (mongooseim, openfire, tigase, ...) which I haven't tried in a long time,
All that's to say that it's amazing that we get so many well maintained and compatible servers (and clients) implementations in XMPP-land, and all the implications for its healthy future.
Poor XMPP, no one will just let it die.
The VC money won't let Matrix die. The community support won't let XMPP die.
I know which I respect more.
It has a long healthy life ahead! Come join the party, the proof is in the pudding.
Its still better than any new chat protocol thats been made in the last decade. You'll have to pry my family XMPP server out of my cold dead hands.
What for?
XMPP is quite robust and open, and while it's not in the level of simplicity of, say, IRC, it still beats pretty much everything else on connectivity and efficiency, and can be run on a potato. Storage is only slighly a concern.
OTOH nu-protocols like Mastodon stuff or Matrix stuff, while they are nice to have, are notoriously badly designed because kiddies these days can't bother to learn C. This results in highly energy-, memory- and storage-consuming systems. In the amount of RAM I need to kick up a Matrix server (assuming it even runs) I can run ~18 XMPP services and about ~240 ircd services.
When you read technical stuff about this protocol, you understand it is a great one and it should not die.
STUN/TURN is literally designed to bypass network boundaries. Its necessity comes from the evil of NAT and allowing RFC1918 IP addresses behind firewalls to poke holes so that direct P2P connections can be established for VOIP.
By virtue of being technology designed to step around boundaries, you should be weary of controls around this. STUN can be used to relay from the external STUN record to other servers within the same broadcast domain. We’ll add some controls here to limit this, but it would behoove you to place this server in an isolated DMZ without connectivity to other, potentially privileged, internal hosts. Never forget network segmentation.```
Would a VLAN be enough?
Yes, absolutely. It all depends on implementation. I am using VLANs for L2 isolation. I have a specific DMZ VLAN that has my XMPP server and only my XMPP server on it. My network core applies ACLs that prevent any inter-VLAN traffic from there, so even if STUN/TURN pokes holes, the most that is accessible is that single VLAN, which happens to contain only the single host that I want to be accessible.
Great question.
all 38 comments