If you're willing to take a punt on a new project then take a look at my post history. I'm working on a fully self contained voice/text/screen share web app that has end to end encrypted DMs built in. The only identifying information it asks for during new account setup is an email address for activation (in an effort to prevent bots) but you can disable that during server setup, have your users sign up with fake email addresses and just manage their accounts manually using the built in tools. It doesn't store IP addresses at all and all the voice/screen share streams are only stored server side long enough to provide a buffer (about 3 seconds worth).
this post was submitted on 16 Mar 2026
37 points (89.4% liked)
Selfhosted
57596 readers
1340 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
And just FYI, use case is simply texting with friends and family, while avoiding state monitoring.
Signal. There's nothing better for security, ease of use, and features. It's a drop in replacement for texts and imessage and facetime.
Thanks for reply. Unfortunately, we can't use it, should be exclusively selfhosted service :( I do like Signal, tho, great app
That's rough. Signal is the only app that can actually be trusted to resist state monitoring because it has a successful history of it.
I guess another option to throw into the pool is https://docs.cwtch.im/ then. It's new though, and not as easy to use.
Be aware that the Signal Foundation still runs servers for the signal service. If a state actor compromises them, e2ee is no longer guaranteed.
It's unlikely encryption would be compromised since the keys never leave the device. The user's device would have to be compromised for that. Decrypting messages on Signal servers without the keys takes too many resources to be feasible en masse, even for a state actor. And the current app has no method to transfer those private/decryption keys.
But Signal is not private. It is only secure. Two totally different things. A bad actor could uniquely identify a user and what users they have communicated with and how often, just not the content of the messages. That metadata is stored on the Signal servers and the company has access. That is the tradeoff for ease of use and keeping malicious accounts to a minimum vs an anonymous IM app.
A compromised server would allow the server to man-in-the-middle all new connections (as in, if Alice and Bob have never talked to each other before, the Server/Eva can MITM the x3dh key exchange and all subsequent communication). That's why verifying your contact's signatures out-of-band is so important.
(And if you did verify signatures in this case, then the issue would immediately be apparent, yes.)
Edit: I was wrong. See below.
This too would likely require compromising at least one of the devices or at the very least compromising both users' ISPs or some other fairly detailed and highly targeted attack, but none of that would require compromising Signal's servers and would make any system's key exchanges vulnerable, even self hosted systems.
Simply compromising Signal's servers might allow disrupting key exchanges from succeeding and thus making it impossible for those users to communicate at all, but not MITM really, at least if we assume there aren't defects in the client apps.
The key exchange is much more complex than something like TLS and designed specifically so that the server can't interfere. With true e2ee the key never passes through the server. This isn't like many other apps that say e2ee, but really mean end to server gets one key and server to end gets another and decryption and re-encryption happens at the server to allow users to access older messages on new devices and stuff like that. Signal just connects the users to each other. The apps do the rest.
They could probably do something if they totally took over the entire Signal network infrastructure, but it's definitely not something they could do undetected. But if a government took over the entire infrastructure, security conscious people would stop using it immediately thus not really worth the monetary and political cost. Otherwise China and others would have already done that to all secure communications. And again, not Signal specific.
Huh - you're right. I went back to Signal's X3DH spec because I was sure I was right, but it seems I misremembered how the "prekey bundles" work: Users publish these to the server, allowing (in my original assumption) for the server to just swap them out for a server/attacker-controlled key bundle for each Alice and Bob.
However, when Alice wants to send Bob an initial message and she gets a forged prekey bundle, Bob will simply not be able to derive the same key and communication will fail, because Bob knows what his SPK private key is, while the server only knows the public key.
Op specifically asked about a self-hosted option. I think it was fair to comment that Signal wouldn't satisfy this requirement.
Right, which is why I didn't reply to op. I replied to a threaded comment that stated that Signal e2ee could be compromised by a compromised server, which is incorrect. Only privacy could be compromised, not e2ee. The specific threaded comment I replied to didn't mention that it didn't satisfy OP, which I also agree with.
The Signal foundation also controls the ends, as they control the official clients and can push encryption breaking updates to end user devices; in cooperation with Google/Apple even to selected devices of individual people which makes this nearly impossible to detect.
For Matrix consider Continuwuity instead of Synapse if you want something easier to maintain. You'll also want to set up Element Call (i.e. the "new" calling stack) for wider client support.
Notifications can be unreliable but it depends on your push provider (e.g. don't use the default ntfy.sh instance, use another one or selfhost yours). Do let me know of any other nits though.
For XMPP, notifications is most reliable as it maintains an in-band connection to the server. A/V is a bit more lacking, as mobile clients can only do 1:1 calls, and it misses some smaller features compared to matrix. But it's very lightweight and should be more than capable for use with family and friends.
Wait this vs tuwunel? I switched to tuwunel because i thought that was the official successor
It's claimed to be official. But I went with https://continuwuity.org/ since it seemed to have a more active community. Plus ever since then, the core maintainer of Tuwunel has been making threats against Continuwuity including personal attacks, and seems to be quite unpleasant to deal with in general. There's also been a thread about it here. So I honestly lost all taste to reconsider.
Prosody (XMPP server). Setup takes an hour at most even if you have never worked with Lua. Easy to interact with (it has a built-in shell), easy on system resources, and easy-to-understand config. Support for groups, E2EE, attachments including videos and voice recordings, among others.
or snikket, the docker version of this with some things pre configuration-tated
Thanks, will check it out. If it's not too bothersome, could you specify why XMPP would be a better choice than other options? The protocol itself, I mean. There's a lot of contradicting info on each of the protocols. Some say XMPP is ancient, choose matrix. Others say matrix is a complicated mess, choose more mature XMPP
As someone who's tried both, it depends on what you want. Your choice of Matrix server depend on any political and ethical values -- some say Synapse is too corporate, being maintained by Element who are for-profit and obtain funding from corps and governments, so some prefer others such as Conduit ( -- until maintaining slowed to near abandonment and it was superseded by Conduwuit -- until the owner got cyberbullied so hard she quit the project and it was superseded by Continuwuity) because it was built on Rust and much more efficient than Synapse, or Dendrite. I recommend Continuwuity.
Then there's clients -- the only mature matrix client for mobiles is Element, and there are two apps, Classic and X, who offer different pros and cons, and imo are not good enough on their own, both are in a kind of beta stasis. But it's the best they have. If you really don't need calling, then Element X, FluffyChat or Schildichat is your app and Element Web for desktop access (available on Github). However, when exchanging encryption keys to trust another of your devices, or a contact's device, only Element offers simple QR scanning.
In short, Matrix is very good as a privacy-focused server with partially working, modern looking clients.
Then there is XMPP. Again there are different backends to choose from and I am inclined to recommend Prosody. XMPP just works out of the box for me, calling included, and is relatively stable. However, there are large caveats -- several pieces of user data are stored unencrypted on the server, which is fine for you as the owner, but it's a lot harder for someone else using your service to trust that. And, while XMPP uses OMEMO encryption keys, handshaking with devices is far more manual than Matrix's Olm/Megolm and involves a multi-step process, and migrating to a new device is a pain because messages are not backwards decrypted, so they must be transferred from the first device. Finally, clients are very rough. The best desktop clients such as Gajim and Pidgin still look like they were built in 2001, and while mobiles have Monocles, Cheogram and Conversations, they all look very similar, as the former are very slight modifications of Conversations.
In short, XMPP may lack some comforts of modern messengers, but it is simpler to set up than Matrix, and offers many of the same features. However, the manual key sharing process might scare off all but the most avid privacy enthusiasts, especially that if you migrate to a new device without sharing message history from a previous verified device, messages are lost.
Choose Matrix for polished software, inviting many contacts, and, with Element X featuring (eventually) Element Call, complete E2EE.
Choose ol' faithful XMPP for an easier initial setup, if video calls are important, you appreciate that historical messages cannot, by design, be hacked into, or if you don't like Element the company.
I too have heard good things about SimpleX and Signal, and recommend trying them if they are valid contenders for your use case. Signal really is the best (most private, least data-farming) non-selfhosted option.
That you think Gajim looks like it was build in 2001 tells me you haven't used XMPP in quite a while 😅
Thank you a lot for such detailed explanation! I finally got a definitive answer to XMPP vs Matrix debate. You definitely convinced me to try XMPP, seems indeed more reliable. In another message, you also mentioned you wrote a guide on Prosody, I actually would love to check it out :)
Oh, and if you wish, it's a bit old now but no doubt useful, I have written installation guides on both Prosody and Continuwuity, based on Proxmox containers.
XMPP is ancient. So is email, the internet, and the wheel.
Lots. But the difficulty as ever is finding something that the people you want to talk about are also using.
Let's just that we all are so fucked, that we'd use anything that works. So that's not a problem to convince them to switch, we all are ready to switch
Gamers Nexus posted a video recently about Discord alternatives.
That was a great video actually. I thought that Zuli was kinda cool, shame it's a paid service. Not that I mind paying, just quite literally can't. Funnily enough, they hit the same issue with broken voice calls on mobile Element client
Well, I think XMPP or Snikket is worth a try and definitely more reliable than Matrix, but you might also want to look at DeltaChat.
There is probably something wrong with your setup, if Synapse has these problems.
I've been running Synapse for years, including voice/videocalls and even video conferences.
That's definitely possible. But the weirdest thing was the inconsistency of every issue. As an example - voice calls worked on the web client, but didn't on mobile. Client issue perhaps, tho I tried, like, almost every mainstream mobile client
Try Delta chat (chatmail server)
Your issues with voice calls are likely because you didn't set them up, and the web client was using the fallback server.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| DNS | Domain Name Service/System |
| IP | Internet Protocol |
| PiHole | Network-wide ad-blocker (DNS sinkhole) |
| SSL | Secure Sockets Layer, for transparent encryption |
| TLS | Transport Layer Security, supersedes SSL |
| XMPP | Extensible Messaging and Presence Protocol ('Jabber') for open instant messaging |
5 acronyms in this thread; the most compressed thread commented on today has 16 acronyms.
[Thread #173 for this comm, first seen 16th Mar 2026, 21:00] [FAQ] [Full list] [Contact] [Source code]