Modern Messaging: Running Your Own Xmpp Server
Posted3 months agoActive3 months ago
codedge.deTechstoryHigh profile
calmmixed
Debate
60/100
XmppSelf-Hosted MessagingDecentralized Communication
Key topics
Xmpp
Self-Hosted Messaging
Decentralized Communication
The article discusses running a personal XMPP server for modern messaging, sparking a discussion on the pros and cons of XMPP, its clients, and its comparison to other messaging solutions.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
19m
Peak period
83
0-6h
Avg / period
16.3
Comment distribution147 data points
Loading chart...
Based on 147 loaded comments
Key moments
- 01Story posted
Oct 6, 2025 at 8:02 AM EDT
3 months ago
Step 01 - 02First comment
Oct 6, 2025 at 8:21 AM EDT
19m after posting
Step 02 - 03Peak activity
83 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 9, 2025 at 12:00 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45490439Type: storyLast synced: 11/20/2025, 7:50:26 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
- single point of failure of rooms (server creating the chat room)
- media access via 3rd party servers
- gossiping encrypted message access across multiple devices
- encrypted audio-visual (group) communication
- good clients for iOS
- reliable server-side storage of messages (of all(!) chats)
- realistic verification concept for e2ee with multiple devices
As others have pointed out, for iOS Monal is good.
Monal looks like something that would be good in 2005, not 2025. There is no way you'll convince people nowadays to use it unless you force them to.
And telling friends and family they need to setup a Jabber connection to talk you will make you "That guy/girl who...". And if the idea spreads, then talking to n people requires n accounts on n servers. At least Pidgin (last time I used it, which was last decade) supports such a configuration. I wonder if the mobile apps can do the same.
No, it doesn't.
XMPP is like E-Mail and Matrix a protocol which supports federation, i.e. a protocol which specifies how many service providers can cooperate, specifically forward messages to other service providers to reach their users.
Ended up using Hey, and it works pretty well, I guess, but a rails PWA is a little heavy duty for my taste, I would prefer XMPP
[0]: https://prosody.im/
The real limits are going to be on hardware. If we want 40M concurrent connections, the server will need a few hundred to a few thousand gigabytes of memory.
Assume 10% of 40M users are active at once. That's 4M clients to deal with. You would need 62 servers (and probably a few for cache) to handle the load. But those could be small core cheap servers.
See https://ats1999.github.io/blog/65535/ or similar pages.
But this was with only 96G of ram, and dual westmere 6-core processors. You can put together a small desktop with consumer parts that will be way more capable today. And if you run everything on a single machine, you don't have to deal with distributed system stuff.
When I left in 2019, we were running on Xeon-D type hardware, with maybe 64 GB ram and IIRC, only doing about 300k connections per chat machine. Chat scales horizontally pretty well, so run a couple machines of whatever, find your bottlenecks and then scale up the machines until you hit the point where it costs more to get 2x of bottleneck on a single machine than to get 2 machines with 1x of the bottleneck. I suspect, if you can get quality AM5 servers, that's probably the way to go for chat; otherwise likely a single server socket would be best; dual socket probably doesn't make $/perf sense like it did 10 years ago. If you get fancy NICs, you might be able to offload TLS and save some CPU, but CPU TLS acceleration is pretty good and there's not a ram bandwidth saving from NIC TLS like there is for a CDN use case.
IMHO, getting a single server to support 4M clients shouldn't be too hard, and it should be a lot of fun. Mostly all the stuff that was hard in 2012 should be easy now between upstream software improvements and the massive difference between CPUs in 2012 and 2025. The hard part is getting 4M clients to want to connect to your server. And trying to setup a test environment. Elsewhere on this thread, there's a like to the process one blog from 2016 where they ran 2 M clients on a single server (m4.10xlarge (40 vCPU, 160 GiB) with a single same spec server as the client load generator; the impressive part there is the client load generator --- I've always needed to have something like a 10:1 ratio of load generators to servers to load down a big server. And they managed to get that to work with all their NIC interrupts sent to a single cpu (which is not what I would have recommended, but maybe EC2 didn't have multiple nic queues in 2016?)
> If there's a way to get more client on a single machine, I'm all ears - but that's baked into IP protocol. TCP/UDP doesn't matter. It's a limitation of IP.
As others have said, the limitation is the 5-tuple: {protocol, SrcIp, DstIp, SrcPort, DstPort}; if you're a server, if you hold SrcIP and SrcPort fixed, and for each dest ip, you can have 64k connections. There are a lot of dest ips, so you can host a lot of connections, much more than you can actually manage on a single system. If your clients are behind an aggressive CGNAT, you can actually run into problems where there's more than 64k clients that want to connect to your single IP and port ... but you can listen on multiple ports and address it that way, and most aggressive CGNATs are only for v4; if you listen on v6, you'll usually see the client's real ips or at least a much more diverse group of NAT addresses.
If you listen on all the ports, you can have 4 billion connections between you and any given IP. That's not going to be limiting for a while.
[1] https://blog.whatsapp.com/1-million-is-so-2011
[2] https://www.erlang-factory.com/upload/presentations/558/efsf...
Now what size of machine?
(I don't really care, and the original question does have a whiff of malicious intent, but scaling discussions are sometimes interesting...)
I'm not necessarily endorsing this, just giving it to you as some first stabs at answers and some ways to follow up.
If there's anyone reading this from the ejabberd project, note that the link to this on your front page under "Massively Scalable" is completely broken; that links to "blog.process-one.net" but that domain is completely dead, so it doesn't redirect to the link I gave above. (It's also part of why I posted this; my post here is not a "just read these docs" because I had to do non-trivial work to find them.) I had to pull that out of archive.org. Should probably check for any other links to that domain too.
IRC.
Spin up multiple VM/Docker/whatever instances with an IRCd daemon, add each IRCd as a leaf.
It does offer almost-linear horizontal scalability.
(disclosure, I work for Tigase)
There's also some weird behavior with how E2EE works, which is causing me problems in group chats. Initially it worked, but now people are unable to read some messages with errors like "this message was not encrypted for this device"
FWIW, everything works great on Android with the Conversations app, and also I admit I haven't really RTFM'd too much so it may be my fault as a lazy admin.
Edit: this is with ejabberd btw
between that and the unwanted features (federation, spaces) that aren't useful in a texting context, no way to search message logs, and a server to maintain.
...
I went back to RCS
Search on mobile (in Element X) is on its way and is making good progress: https://youtu.be/Q6NSmptZIS4?t=1297 from a demo from a few days ago.
Finally, self-maintaining servers now exist (https://element.io/server-suite, complete with AGPL distro: https://element.io/server-suite/community)
(On the other hand, notification reliability on Android is still a known problem on Element X for some users that we're working on.)
And there's no way it's more secure anyway, cause your secret is just a 4-digit pin.
The intersection of developers who want to develop on and for a proprietary walled platform and also want to work on open source clients for open standard, descentralised protocol must be pretty small.
If anyone reading this thread has iOS dev skills and cares about improving open-source messaging on iOS, feel free to get in touch.
Now if only it actually worked consistently and reliably.
I'm not being snarky, the app is flakey as hell. Reactions are nice and all but pointless if they don't have the send a message part down.
It does. I use a self hosted Matrix server for chat with friends (multiple servers federated, even!) and it is rock solid.
There’s an extra step that could have been skipped entirely there and we’d be better off.
client - server - server like?
Pidgin implemented support for various networks under an abstraction layer and had a unified UI for all of them.
XMPP implements this via gateways. I used to talk from XMPP with folks who used MSN or Yahoo on their end. We have gateways for Telegram, WhatsApp and Signal nowadays.
The Nokia N900 used the Telepathy framework to expose a local D-Bus messaging service which itself connected to various networks (SMS, MSN, XMPP, etc). The UI was a single unified one for all these networks.
Have you looked at the protocol? Have you built things in both? I have, and I think the Matrix protocol is pretty good. The goals are different. It's not a send once and forget kind of thing, like XMPP, Signal and email. It's about keeping your chats synced on your server, and with any other server you happen to be federating with. It's Discord or Slack, except federated. That's not easy, and it's not simple, but it has huge advantages too.
And huge disadvantages. I don't understand why everything has to be centralized/ routed through an intermediary. Well I do understand it, modern big corps wants to be that intermediary for various reasons, but thats a business reason not a technical one.
hence, matrix by definition was born due to business reasons and not technical.
In other words, this wasn't really a "hey we need to sell messaging apps to telcos" play - it was a long-term R&D experiment, more like Bell Labs funding UNIX.
I was sufficiently "high up" in organization to hear this pitch. For record I said that they (telecoms) won't buy it and I didn't like project technically
Later when Amdocs saw that it's a no go they span you outside and later cut the funding.
it was initiated very much by me & the UC team while inside Amdocs.
> it (given that it was amdocs) was meant to be sold to telecoms to compete with OTT offerings
in the 5-10 year horizon, yes. And indeed eventually (as Element) we have ended up with a bunch of telco customers. However, this was not the immediate goal at the time - it's not like Matrix was created to improve EBIT for Amdocs UC; it was a long-term R&D play.
> Later when Amdocs saw that it's a no go they span you outside and later cut the funding.
It was the opposite. Amdocs saw that Matrix had legs - e.g. Ericsson started selling Matrix-based solutions (stuff like https://matrix.org/blog/2016/11/23/when-ericsson-discovered-...) - but also saw that it didn't fit inside Amdocs. The whole idea of Matrix is to be an open standard for everyone, just like XMPP or SIP or HTTP. For it to succeed, it obviously couldn't live inside Amdocs.
So, they agreed to both cut funding and span us out; we then raised funding independently and set up The Matrix.org Foundation as non-profit to look after Matrix for everyone, and separately set up Element as for-profit to fund our work on Matrix. It's not exactly been a smooth journey (see https://youtu.be/lkCKhP1jxdk?t=363 for my FOSDEM talk trying to explain the route so far), but I can confidently say that Matrix was not borne out of trying to scratch an immediate business itch for Amdocs, but instead a longer-term experiment in building something better for everyone (including Amdocs).
But what do I know :D
Disclaimer: I have a lot of XMPP experience but have never used Matrix
centralized? no
If you sign up for messaging on let's say Signal, do you really want your client to talk to Facebook, Google and dozens of other services?
And do you want the users of your chat service depend on "random" other services ? Not being able to access chats, media, because an outage or even shutdown of a random service over which you don't have control?
If you allow for forwarding in between, there are p2p messengers. Messages are stored - if at all - using store & forward techniques. They can use the internet, but also bluetooth and other communication technology to transmit messages. The most popular ones would be Briar and Jami. Matrix P2P exists at an experimental stage as well (moving servers onto devices).
The problem with them you give up convenient things, even though there are often are workarounds. For instance, plain p2p you cannot communicate with offline devices, but store and forward techniques exist, either storing messages on random people or dedicated store and forward servers.
Battery drain, lack of reliability. It's just extremely simple, quick and reliable to send messages to a defined server and receive Push Notifications via push service.
Want a reliable storage of your messages (encrypted) such that you can always access them when you wish? well...
That is how "the internet" has worked forever.
People have been running servers on their own home machines, for a long time. If you really want you can setup a webserver/sshd/etc. on your own machine and access it from the outside if you don't care about DNS and static IP. Will also probably need to port forward at the router, though.
Its less common nowadays due to the cloud, and security issues, etc. sure. And I'm not sure to what extent its possible over mobile.
But for two people who are on PCs/Macs, it should definitely be possible. And it would be much lower latency because you don't have to bounce it off another server.
https://delta.chat/en/2024-11-20-webxdc-realtime
Wouldn't work well for more than a few people, but not every conversation has group sizes that large.
- direct connections are really hard (Tailscale built a whole company on solving this one problem)
- even Tailscale can't establish direct connections without a coordination server
- even if you can reliably, and always, establish direct connections, it doesn't matter if someone is offline
- push notifications don't work without a server, on Android or iOS, so even if you're online, you're out of luck (won't ever get a new message because there's no push notification to tell the client to connect, and you can't just leave a TCP connection open forever on a mobile phone)
My take is that it's fine to have a server in the middle with E2EE. That's the whole point of E2EE.
I get that not everyone would accept a web-app replacement, but it sure would be nice if iOS wasn't actively obstructing the possibility of some folks using a web-app messaging service.
There is an nginx-xmpp to proxy it, but it is archived. https://github.com/robn/nginx-xmpp
For that reason http based protocol just seems much easier on the network or something that can be easily reverse proxied without extensions will be easier to self-host and have wilder internet connection accessibility.
https://prosody.im/doc/setting_up_bosh
https://prosody.im/doc/modules/mod_websocket
But I never tried it myself and from a quick search the popular non-browser XMPP apps/clients don't seem to use it.
For reference: https://www.someodd.zip/phlog-mirror/xmpp-server.gopher
BOSH still has some interesting trade-offs even today. It can help with some NAT headaches and rides over plain HTTPS. I like this old post:
https://metajack.im/2008/07/02/xmpp-is-better-with-bosh/
Curious who here uses BOSH in production and/or WebSocket (RFC 7395) these days.
But it's also totally possible to run XMPP over 443, and this is a feature of many popular XMPP deployments. If you're self-hosting, there are some guides for different deployment approaches here: https://wiki.xmpp.org/web/Tech_pages/XEP-0368
I left in 2019, but when I was there, WhatsApp used port 5222, but the client would try port 443 if port 5222 didn't work. After it had tried those enough, it would try on port 80 with HTTP wrappers.
Really, the right model for a public service is what AOL did for AIM. Listen on all the ports. Clients should try on the 'proper' port, then 443, then 80, then random permutation. Skip certain ports because nobody likes it if you probe on smtp, smb, or chargen (etc)
But they say port 5223 and 2197 with fallback to 443 [1]. Google says 5228-5230 and 443, with a couple outliers [2].
[1] https://support.apple.com/en-us/102266
[2] https://support.google.com/work/android/answer/10513641?hl=e...
Although the big issue with this is that clients need to have wireguard enabled at all times, otherwise they can't even receive notifications. It's kind of a PITA for non techies to understand, and also kind of a PITA for techies who may already be using wireguard for something else, as Android/iOS don't let you have multiple VPNs active at once.
It may be better to expose my ejabberd service to the internet directly. Even if it gets hacked, messages are E2EE at least.
Specific security audits would have to be searched for, though.
[1]: https://snikket.org/open-source/
I've proposed a specification for SFU hosting (check https://bloggeek.me/webrtcglossary/sfu/ if you don't know what's a SFU), and wrote a component based on the excellent Galène SFU, as well as client implementation (in Libervia) as part of a NLNet/NGI grant (https://nlnet.nl/project/Libervia-AV/).
XMPP council (disclaimer: I'm a council member for the current term) asked me to some modifications and to re-propose, which I'm about to do. I couldn't find the time so far (cause I'm working on ton on stuffs), but will go back to it very soon.
To sum-up: this is very much worked on.
Also note that Libervia is using a backend/frontends architecture with a D-Bus API, you can use it to make your own frontend with any language you like.
If this come to pass, there will be two approaches:
1. People will not share anything important online, only in person
2. Every friends group will have a more technical guy/girl who will ran chat infrastructure for them
Interesting article though :)
Given our current surveillance state with social networks, I don't see (1) or (2) as real options.
One thing I do agree with is that collaboration tools have to come first. We've become unable to do anything without a company/boss, completely atomized. Three or four programmers/designers who hang out should be able to do anything together. Put them in a downtown office with some MBA prick alternately yelling at them and kissing their asses, and they can build empires that they get to share 5% of.
I've got a nice mailu config and wanting to expand with Nextcloud (or alternative) and likely xmpp services... I mostly use a pretty light host VM and docker compose configuration to make up/down/backup/restore pretty smooth... I'm not currently running across multiple servers, but do want to be able to have a slightly more consistent config... I've got a combination of Caddy and Traefic on the different servers for TLS and all my apps are /apps/appName/(data|docker-compose.yml) on the server(s). Which keeps my maintenance chores relatively simple from a couple remote ssh commands and rsync.
Mostly been a bit lazy in terms of getting this all done.
I switched to Nextcloud Talk after Skype shutdown and migrated all my family there. They love it. We have a private cloud, we can share photos and other files, great mobile support... The only issue at the moment is relatively long delay before receiving a message (up to 30secs?) since I've been too lazy to setup redis.
There is zero reason for long delays or lost messages in XMPP.
I've written multiple parsers along the way, back in the days when there was nothing else and more recently for use in very constrained embedded contexts.
I don't know how much has changed, but it was more complicated than I would have wished, seemingly designed more to check theoretical boxes than for ease of use.
I was also part of a project where the backend was implemented as a bunch of services communicating via XMPP, custom server etc. And it was a total mess, we spent a lot of time on manual intervention just making sure messages weren't dropped.
Is this a common experience with XMPP or did I just hit all lemons?
Good times, I feel old now.
But the clients are lacking. On linux there is gajim that is "okish" but it lacks calling capacity with mobile clients. On mobile there is conversation and derivatives on android which are "nearly there" and monad on iOS.
Globally, the main lacking features are:
- voice and video calls cross platform
- gif integration, tenor/giphy/imgur...
- fast sync (if you open gajim after being offline for a week, it takes ages to catch up)
Plus, you're not leaking all the tracking associated with those widgets.
However, I understand that people have come to expect having fun experiences in their IM clients, and that usually requires reacting with animated GIFs.
(I'm the author)
In my book it only got worse. Way worse. Sure, it looks more familiar to those who is used to iMessage/Whatsapp/Telegram, but I bet it would still look quite alienating for that audience. And for those who remember Gajim 1.x, disastrous UX doesn't outweigh introduction of reactions, history syncing and whatnot. Last time I checked it a couple of months ago:
- It was not possible to close group chat without leaving MUC.
- I had to constantly open separate search dialog to write to someone who's already in my roster but is not in the list of active chats.
- Speaking of active chats: what annoys me the most about modern IM clients (and that includes Gajim 2.x) is that list of chats is sorted by the last activity date. I don't even know how Whatsapp/Telegram users live with this, I got so fed up with hovering my mouse/finger over one chat and tapping it only for the whole thing to reorder in the last jiffy and opening something completely different, I just dropped my account from one of those centralized mass-market services altogether. It is that annoying.
- It had lots of smaller warts like nickname autocompletion requiring way more key presses (especially after someone mentions you).
The clients are great (they have reactions!)
there is even a really good app store associated : https://webxdc.org/
It's kinda cool. If or when, I need to setup new communication needs, I might use this. (Currently do not have a need for any)
https://homebrewserver.club/category/instant-messaging.html
That reminds me of one idea I had back in the day. You see, not everyone has the skill nor time to set up their own server, so clients rely on 3rd party servers. But sometimes these servers either experience intermittent connectivity issues or just die out altogether, which means users now have to set up second account and re-add everyone, while also scattering chat history across multiple accounts. What I'd like to see is some way of linking accounts across multiple servers, so that:
- message delivery could have transparent fallback (it gets delivered to me@bar.com if me@foo.com is unavailable)
- you don't have to add and authorize multiple accounts
- rosters and chat histories also get synchronizes between the two
A lot of that could probably be hacked around just on the client side, and I don't have good answers to questions like "what happens if I want to unlink two accounts for some reason".
(And going a bit off-topic: I also wish I could use multiple email addresses while registering in other places, because email provides too can fail, close altogether, or even just ban you for no good reason while also having crappy bot-driven support@.)
It's a bit the same feeling like RabbitMQ, which I'm no longer using that much, but I also always thought that it is a reliable software. I've wondered if it is related to them being written in Erlang.
For anyone curious, I documented the full process (including IRC bridge + more!) here:
https://someodd.zip/phlog-mirror/xmpp-server.gopher
I also covered audio/video calls using a companion STUN/TURN server:
https://someodd.zip/phlog-mirror/xmpp-server-video-audio-cal...
Curious how others here are handling federation and mobile clients these days. I use Conversations (F-Droid) and Gajim.
> [multiple A records]
"A" DNS records may be used for a fallback, but SRV records are the primary way to configure those [1, 2]. Also some of those can reuse an existing domain name, and some may not have any DNS RRs, but only be used as an internal JID.
> ejabberd is a robust server software, that is included in most Linux distributions.
Prosody [3] is another nice and popular option.
> Install from Process One repository
> Install from Github
Both ejabberd and Prosody are available from regular Debian repositories as well.
> Make sure the fowolling ports are opened in your firewall, taken from ejabberd firewall settings.
A port range is also needed for TURN, to use for relaying. And there is a typo.
> Clients I can recommend are Profanity, an easy to use command-line client, and Monal for MacOS and iOS.
Among relatively feature-rich and user-friendly ones (quite polished, supporting more recent standards, including voice calls with DTLS-SRTP, OMEMO), there are also Conversations for Android, Dino for Lignux (GUI), poezio for TUI (though that one has no voice calls). Setting converse.js (a Web client) may also be convenient (and done rather easily, at least with Prosody).
[1] https://www.rfc-editor.org/rfc/rfc6120.html#section-3.2.1
[2] https://xmpp.org/extensions/xep-0368.html
[3] https://prosody.im/
1 more comments available on Hacker News