Last time I tried this I couldn’t even find an iOS client that supported reactions. Hate on the complexity of Matrix all you like, but at least when you ask your family to use it, they get a modern experience and don’t feel like they’re giving up everything vs every other messenger they are used to.
I recently tried to move people over, and the iOS situation is bleak. It seems like notifications don't work at all in any app, which is a big problem for chat. Also, one of them (I think Siskin?) doesn't display sender name/avatar in group chats, so you can't tell who sent what.
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.
Monal works great on iOS in my families experience. They've never missed a notification and E2EE (OMEMO) never failed. We are using the conversations.im server however.
> Last time I tried this I couldn’t even find an iOS client that supported reactions. Hate on the complexity of Matrix all you like, but at least when you ask your family to use it, they get a modern experience and don’t feel like they’re giving up everything vs every other messenger they are used to.
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.
There isn't a single XMPP client for iOS that properly follows the iOS HIG and isn't ugly or unusable. There are very few clients that are even fully featured. The XMPP landscape on macOS is even more bleak.
I’m using Monal and it’s decent. Agree reactions are a big thing missing, but notifications etc have been flawless which was a harder requirement for me
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.
when my family used matrix for a couple years the e2ee features would randomly fail to decrypt history and would present my non technical family with that "match these emojis to unlock your account" screen all the time.
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.
As much as I like the idea of XMPP, I don't have good experiences from interacting with it. Neither clients nor protocol/server level.
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?
I'm running ejabberd in my home network and together with Conversations (Android app) it is my solution to have all devices report their status to my phones, tablets and pc. Easy to upgrade (when used with Docker), never complains.
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.
I’ve been running Prosody [0] for many years now. Don’t ask me why I chose it over another server. I used to have a jabber.org account that I used before that, already back when I could use jabber to communicate with gchat and facebook messenger users. Alas, nowadays, it’s just my wife I use it to communicate with :(
Prosody is sweet. I forget why I switched over from ejabberd, but it it was quite reliable and had such a huge breadth of extensions it supported. Ejabberd has been intimidating to setup but really wasn't hard, but Prosody was a snap.
"Since 3 years the European Commission works on a plan to automatically monitor all chat, email and messenger conversations.12 If this is going to pass, and I strongly hope it will not, the European Union is moving into a direction we know from states suppressing freedom of speech."
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
On #2, even though I and most of my friends/family are in the US, likely going to offer such to friends and family... I'm about to move from a /29 to /28 subnet to run a few extra services on my hosted server.
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.
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.
You don't need any third party modules and can proxy based on ALPN (https://wiki.xmpp.org/web/Tech_pages/XEP-0368#nginx) thus running everything on port 443. Note that ALPN is not encrypted AFAIK but public wifi services don't care.
The default ports are often blocked on such networks (public wifi, corporate firewalls, etc.), but also often open. 5222 is used by e.g. WhatsApp, 5223 is used by e.g. Apple push notifications. So it's not as bad as it could be.
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
Good stuff. I run my own ejabberd server and it's been great. Installation is relatively straightforward, configuration isn't terribly convoluted, and it "just works" once up and running. Now my server doesn't have a ton of load on it, as it's used mainly for development / experimental purposes at the moment, so I can't say much about it's scalability or anything. But generally speaking, I installed it, did the initial setup, and other than adding/modifying users, I've rarely had to think about it since.
I love XMPP. I've never missed a notification with it and I wished I switched back to it sooner rather than sticking with Matrix, I do wish it gets more love these days. I've been tempted to make my own desktop client and integrate VoIP with something like Mumble to achieve a Discord like experience with voice channels, but that's way beyond my pay grade.
Part of my thoughts... though if you're familiar with Ansible, the automation isn't so bad in that ecosystem. I mostly run my personal stuff single instance, so deploying /apps/app-name/docker-compose.yaml is my general approach to most things along with either Caddy or Traefik.
For people who want an easier approach, both NethServer and Cloudron have this packaged as an app for people who self host. The Cloudron one is not official yet and is a community developed one.
Signal is a walled garden and might even leave the EU soon. Of course if that happens, XMPP clients will also be harder to get, but at least I will always have full control over my XMPP server.
Thanks! Same for me, it just works. Even regular updates run smoothly with ejabberd. I also do audio calls with it, and it is just a pleasant experience.
Here's a blog post on scalability from the front page (well, sort of, see last paragraph): https://www.process-one.net/blog/ejabberd-massive-scalabilit... This includes not just textual claims about scalability but a lot of hooks you can use to followup on, like a reference to the Tsung benchmarking tool you can use. If you're asking about this for serious reasons, at this scale you're obviously running your own tests anyhow. You may also want to speak directly to Process One about this because it sounds like you're at a scale where you should probably be looking at paid support anyhow.
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.
I'm past my edit window now so I can't remove the claim, but I will verify and agree that it is fixed now. If you (the reader, not Metalhearf) previously visited the home page you may have to manually reload to bust the cache to see the correct link(s) now.
If you’re running a single machine, you’ll be limited by the number of available ports. It’s a TCP limitation and nothing to do with XMPP. You’d need a cluster of XMPP servers to handle 40M users. Even for just text. Port limits are port limits.
You're thinking of outbound port limits. Inbound connections all come in on the same port and there's no port-related limits there.
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.
Unless you're doing multicast or anycast, there's a port bound IP handshake that happens. You have your listener (your server port) and the connected TCP/IP client (client port, on the server machine). You're limited to 64533 clients (0-65535 but the first 1000 are reserved). 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.
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.
The uniqueness tuple for IP is (source IP, source port, dest IP, dest port). You're limited to 65,535 connections from the same two IPs on the same port, but that's not relevant to XMPP which uses only one and some transient things for file transfer and such. At worst having that many people behind one NAT will be a problem... which at this scale could be an actual problem, but there are still solutions (multiple ports being the easiest, and the fact this cluster will probably be on multiple public IPs anyhow).
Maybe for friends and family? But then, if their phone might be compromised by the state...
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.
> And if the idea spreads, then talking to n people requires n accounts on n servers.
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.
Does anyone use ejabberd inside a wireguard network? I'm hoping to set it up on the main server, and connect to it with aTalk on Android - but I'm worried ssl is going to be a pain if it's not exposed with a proper domain name. I don't know if aTalk will accept a self-signed certificate (or even better, just use non-ssl with an address and port without a domain name)?
You should be able to use a DNS provisioning through Let's Encrypt assuming you're on a supported host for your DNS based provisioning. Traefik may even have an easy button option depending on your configuration.
I was thinking of setting something like this up on a Tailscale network, and figured I'd just get real certs for the servers in question using DNS challenges, which I've been able to do with my tailnet (driven by Headscale) for a while now. But even if not, if your root cert is in your device's trust store, then an app would have to go out of its way to only trust well known CAs.
I have this setup, but I haven't tried using a self signed cert. I just have a public domain with the DNS pointing to the ejabberd internal IP. Setting up LetsEncrypt with DNS auth isn't that difficult, and I'm using Digital Ocean for their free DNS API to automate renewals.
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.
ejabberd should work fine, it won't care. But you're right - whether apps will allow you to accept self-signed certificates can vary. Some are strict and don't allow bypass, others may just issue a warning prompt that you can dismiss. I haven't personally tried aTalk.
I'm sorry but there's no way you can call xmpp modern messaging.
Matrix with all of its shortcomings looks like 2050 compared to xmpp.
Xmpp doesn't even have any half-decent mobile client!
Although material like this is extremely important, instructions like 'Fill in the IPv6 addresses accordingly.' are a roadblock to anyone who isn't particularly knowledgeable about networking. You could argue that those people should go away and learn, but not everyone has the time or frankly the ability to do so.
Last time I tried this I couldn’t even find an iOS client that supported reactions. Hate on the complexity of Matrix all you like, but at least when you ask your family to use it, they get a modern experience and don’t feel like they’re giving up everything vs every other messenger they are used to.
I recently tried to move people over, and the iOS situation is bleak. It seems like notifications don't work at all in any app, which is a big problem for chat. Also, one of them (I think Siskin?) doesn't display sender name/avatar in group chats, so you can't tell who sent what.
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
Monal works great on iOS in my families experience. They've never missed a notification and E2EE (OMEMO) never failed. We are using the conversations.im server however.
> Last time I tried this I couldn’t even find an iOS client that supported reactions. Hate on the complexity of Matrix all you like, but at least when you ask your family to use it, they get a modern experience and don’t feel like they’re giving up everything vs every other messenger they are used to.
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.
There isn't a single XMPP client for iOS that properly follows the iOS HIG and isn't ugly or unusable. There are very few clients that are even fully featured. The XMPP landscape on macOS is even more bleak.
I’m using Monal and it’s decent. Agree reactions are a big thing missing, but notifications etc have been flawless which was a harder requirement for me
And alas web push notifications on iOS remain very critically buggered beyond measure. https://webventures.rejh.nl/blog/2024/web-push-ios-one-year/
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.
when my family used matrix for a couple years the e2ee features would randomly fail to decrypt history and would present my non technical family with that "match these emojis to unlock your account" screen all the time.
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
fwiw, the vast majority of Matrix encryption errors got fixed by 2024 (https://www.youtube.com/watch?v=FHzh2Y7BABQ etc).
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.)
As much as I like the idea of XMPP, I don't have good experiences from interacting with it. Neither clients nor protocol/server level.
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?
I'm running ejabberd in my home network and together with Conversations (Android app) it is my solution to have all devices report their status to my phones, tablets and pc. Easy to upgrade (when used with Docker), never complains.
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.
I’ve been running Prosody [0] for many years now. Don’t ask me why I chose it over another server. I used to have a jabber.org account that I used before that, already back when I could use jabber to communicate with gchat and facebook messenger users. Alas, nowadays, it’s just my wife I use it to communicate with :(
[0]: https://prosody.im/
Prosody is sweet. I forget why I switched over from ejabberd, but it it was quite reliable and had such a huge breadth of extensions it supported. Ejabberd has been intimidating to setup but really wasn't hard, but Prosody was a snap.
"Since 3 years the European Commission works on a plan to automatically monitor all chat, email and messenger conversations.12 If this is going to pass, and I strongly hope it will not, the European Union is moving into a direction we know from states suppressing freedom of speech."
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 :)
On #2, even though I and most of my friends/family are in the US, likely going to offer such to friends and family... I'm about to move from a /29 to /28 subnet to run a few extra services on my hosted server.
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.
3. Normal people accept surveillance and techies are tracked down / silenced.
Given our current surveillance state with social networks, I don't see (1) or (2) as real options.
I hope not; I hope there is a culture change; but, hope is not a strategy so it's better to build alternative tools and learn how to use them
One potential issue with XMPP is the default port is commonly blocked on public wifi.
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.
At least Prosody implements BOSH (xmpp over http) and communication over Websocket.
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.
with chat control on the horizon, they should probably consider implementing it
You don't need any third party modules and can proxy based on ALPN (https://wiki.xmpp.org/web/Tech_pages/XEP-0368#nginx) thus running everything on port 443. Note that ALPN is not encrypted AFAIK but public wifi services don't care.
The default ports are often blocked on such networks (public wifi, corporate firewalls, etc.), but also often open. 5222 is used by e.g. WhatsApp, 5223 is used by e.g. Apple push notifications. So it's not as bad as it could be.
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
For TLS I would recommend https://github.com/pingooio/pingoo instead which has automatic certificate management and is really easy to setup.
Good stuff. I run my own ejabberd server and it's been great. Installation is relatively straightforward, configuration isn't terribly convoluted, and it "just works" once up and running. Now my server doesn't have a ton of load on it, as it's used mainly for development / experimental purposes at the moment, so I can't say much about it's scalability or anything. But generally speaking, I installed it, did the initial setup, and other than adding/modifying users, I've rarely had to think about it since.
I love XMPP. I've never missed a notification with it and I wished I switched back to it sooner rather than sticking with Matrix, I do wish it gets more love these days. I've been tempted to make my own desktop client and integrate VoIP with something like Mumble to achieve a Discord like experience with voice channels, but that's way beyond my pay grade.
If you're looking for something that's a little less hassle and has some very sane defaults, try https://snikket.org/
Has anyone done a security review of their source code?
It is simply Prosody + Conversations + Siskin [1], so I'd say that many people have had their eyes on their code.
Specific security audits would have to be searched for, though.
[1]: https://snikket.org/open-source/
I've forgotten how much hassle installing applications can be since docker.
Part of my thoughts... though if you're familiar with Ansible, the automation isn't so bad in that ecosystem. I mostly run my personal stuff single instance, so deploying /apps/app-name/docker-compose.yaml is my general approach to most things along with either Caddy or Traefik.
Here are the official docs for deploying ejabberd using containers: https://docs.ejabberd.im/CONTAINER/
For people who want an easier approach, both NethServer and Cloudron have this packaged as an app for people who self host. The Cloudron one is not official yet and is a community developed one.
If you plan to communicate with people not in the techsphere, Signal is probably the best bet to convince people to switch to.
Signal is a walled garden and might even leave the EU soon. Of course if that happens, XMPP clients will also be harder to get, but at least I will always have full control over my XMPP server.
Thanks! Same for me, it just works. Even regular updates run smoothly with ejabberd. I also do audio calls with it, and it is just a pleasant experience.
Any idea what kind of server we’d need to handle 40M users if it’s just text chat (no files or audio)?
Here's a blog post on scalability from the front page (well, sort of, see last paragraph): https://www.process-one.net/blog/ejabberd-massive-scalabilit... This includes not just textual claims about scalability but a lot of hooks you can use to followup on, like a reference to the Tsung benchmarking tool you can use. If you're asking about this for serious reasons, at this scale you're obviously running your own tests anyhow. You may also want to speak directly to Process One about this because it sounds like you're at a scale where you should probably be looking at paid support anyhow.
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.
Thanks for noticing, it should be fixed now.
I'm past my edit window now so I can't remove the claim, but I will verify and agree that it is fixed now. If you (the reader, not Metalhearf) previously visited the home page you may have to manually reload to bust the cache to see the correct link(s) now.
Thanks, I've forwarded it to their chat channel.
> Any idea what kind of server we’d need to handle 40M users if it’s just text chat (no files or audio)?
IRC.
Spin up multiple VM/Docker/whatever instances with an IRCd daemon, add each IRCd as a leaf.
If you’re running a single machine, you’ll be limited by the number of available ports. It’s a TCP limitation and nothing to do with XMPP. You’d need a cluster of XMPP servers to handle 40M users. Even for just text. Port limits are port limits.
You're thinking of outbound port limits. Inbound connections all come in on the same port and there's no port-related limits there.
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.
Unless you're doing multicast or anycast, there's a port bound IP handshake that happens. You have your listener (your server port) and the connected TCP/IP client (client port, on the server machine). You're limited to 64533 clients (0-65535 but the first 1000 are reserved). 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.
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.
The uniqueness tuple for IP is (source IP, source port, dest IP, dest port). You're limited to 65,535 connections from the same two IPs on the same port, but that's not relevant to XMPP which uses only one and some transient things for file transfer and such. At worst having that many people behind one NAT will be a problem... which at this scale could be an actual problem, but there are still solutions (multiple ports being the easiest, and the fact this cluster will probably be on multiple public IPs anyhow).
See https://ats1999.github.io/blog/65535/ or similar pages.
40M users don’t all simultaneously send messages, or does XMPP need to sustain an open connection to each user?
Yes, you need to have open connection to receive messages.
Or push notification support (which is the same, but basically the OS (Android/iOS) is the thing holding an open connection :) )
You can put multiple IPs on a computer. (Or VMs, LXCs, etc. which would each get an IP)
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 couldn't get iOS notifications to work properly when I tried to set up ejabberd.
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
I cannot say, that I have problems with it. I use monal on iOS and whenever someone mentions me, I get a notification.
the only problem, as usual, is the network effect
Maybe for friends and family? But then, if their phone might be compromised by the state...
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.
> And if the idea spreads, then talking to n people requires n accounts on n servers.
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.
what about
- 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
Not my project, but I was hoping to see more stuff like https://prose.org/
As others have pointed out, for iOS Monal is good.
> 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.
yunohost installations include the metronome XMPP service enabled out of the box. it's similar to prosody
Does anyone use ejabberd inside a wireguard network? I'm hoping to set it up on the main server, and connect to it with aTalk on Android - but I'm worried ssl is going to be a pain if it's not exposed with a proper domain name. I don't know if aTalk will accept a self-signed certificate (or even better, just use non-ssl with an address and port without a domain name)?
You should be able to use a DNS provisioning through Let's Encrypt assuming you're on a supported host for your DNS based provisioning. Traefik may even have an easy button option depending on your configuration.
I was thinking of setting something like this up on a Tailscale network, and figured I'd just get real certs for the servers in question using DNS challenges, which I've been able to do with my tailnet (driven by Headscale) for a while now. But even if not, if your root cert is in your device's trust store, then an app would have to go out of its way to only trust well known CAs.
I have this setup, but I haven't tried using a self signed cert. I just have a public domain with the DNS pointing to the ejabberd internal IP. Setting up LetsEncrypt with DNS auth isn't that difficult, and I'm using Digital Ocean for their free DNS API to automate renewals.
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.
ejabberd should work fine, it won't care. But you're right - whether apps will allow you to accept self-signed certificates can vary. Some are strict and don't allow bypass, others may just issue a warning prompt that you can dismiss. I haven't personally tried aTalk.
I'm sorry but there's no way you can call xmpp modern messaging. Matrix with all of its shortcomings looks like 2050 compared to xmpp. Xmpp doesn't even have any half-decent mobile client!
Although material like this is extremely important, instructions like 'Fill in the IPv6 addresses accordingly.' are a roadblock to anyone who isn't particularly knowledgeable about networking. You could argue that those people should go away and learn, but not everyone has the time or frankly the ability to do so.
Take a look at https://snikket.org .