Years ago, I set up a Matrix server. I got some people to migrate, but ultimately even my husband stopped using it because the UI and accessibility of all the applications was so poor (and he has very bad eyesight, so this was a dealbreaker)
Looking for another alternative, I ended up with Telegram. It was pretty open, easy to work with, had great UI and even a ton of funny stickers and emojis, so I got nearly all my friends to migrate. I did NOT go for Signal because I do not need end-to-end encryption all the time, and having all the same conversations available on my desktop as well as on my phone was important, and still is. Unfortunately, it's also run by a severe weirdo.
So yeah, I'm not really sure what to use now.
What I found with Matrix was the same terrible experience you describe, so I gave old XMPP a new look, and it's been great and continuously improving since. I sleep much better at night having my whole family using XMPP over a self-hosted ejabberd than I can using Matrix to talk with them (and synapse... Forget using synapse federated).
This is how I got kicked off LINE… they had a Chromium app that I could use tethered to an app, they disabled support for LINE Lite (which had light/dark theme, E2EE, texting, voice/video calls, debatable trackers (Firebase), even stickers & sending a location @ 8MiB instead of 200MiB+ of the “heavy app”), I refused to “upgrade” as it was a downgrade to me, & since I was no longer registered with a “primary” device, I was booted from the network. I don’t think I want these mobile-duopoly-required apps to be my primary means of communication with folks—especially now that my primary phone isn’t Apple or Google (luckily Open Whisper lets WhisperFish exist).
Curious what you mean by this. I use the Signal Desktop app. It does what it's supposed to - send and receive messages in a timely way with no lag.
What poor performance are you seeing? What doesn't integrate?
If GP's system resources are usually dedicated to other tasks, perhaps trying to run an Electron app on top of those led to resource contention, and poor performance. You wouldn't notice this if your hardware is overprovisioned for the things you do with it.
1 - https://support.signal.org/hc/en-us/articles/360008216551-In...
Its overall a little sluggish in general (like most Electron apps though, in fairness) and occasionally clicking and dragging images onto the application will cause it to freeze and eventually crash.
Plus, the general usability issues present in all variants of the signal client (like no easy way of restoring previous messages on a new device).
It's not terrible or anything, but it's just a solid 6/10 application. I personally wish they were more open to 3rd party clients, so I could have something that integrates with my desktop environment a little better and is snappier, like my Matrix clients.
Marlinspike, Acton, or someone else? Why does this matter?
> I still use Signal for most day-to-day conversations and I’m not planning to stop.
You can run a Signal-XMPP gateway. See https://slidge.im/
This will allow you to use your Signal account from your XMPP client. Bridging audio / video calls isn't currently possible. But most other feature work across the gateway.
I once looked into that and it just confuses me, it’s XMPP but requires an invite? And the snikket client only works with snikket servers, yet it’s actually all based on prosody and conversations? Everything about the project has alarms going off for me.
The Snikket client works with any XMPP server, and the Snikket server works with any XMPP client.
The Snikket clients are soft forks of existing clients. The reason of their existence is having consistent branding.
In fact, I recommend using Monal as an iOS client instead of the Snikket iOS one.
Note: you can set up invites on any regular Prosody / ejabberd server.
https://prosody.im/doc/modules/mod_invites
https://docs.ejabberd.im/admin/configuration/modules/#mod_in...
Prosody is a popular choice of XMPP server software. It's used for all kinds of stuff, from self-hosted chat servers to powering Jitsi Meet, to Internet-of-Things applications.
Prosody is extremely flexible, and has a bunch of configuration options that allow you to adapt it and extend it however you want. For some people, this is ideal. Those people should continue using Prosody.
Snikket has a different scope. It is specifically an answer to a question like "How can I easily make a self-hosted WhatsApp/Signal for my family/friends using open-source software?"
- Snikket contains Prosody, for the core chat part. But it's Prosody with a very specific configuration, and the configuration is part of the project, it's not intended to be modified by the person deploying Snikket. They only need to provide the domain name.
- Snikket also includes additional components that a modern chat service needs. For example, it includes a STUN/TURN server to ensure that audio/video calls work reliably (again, preconfigured).
- Snikket provides its own apps, which are tested and developed in sync with each other and with the server. This avoids the common problem of incompatibilities that occur when you have an open ecosystem such as XMPP, where different open-source project developers may develop features at different paces, leaving users to figure out which ones support which feature. It also solves the discoverability and decision fatigue for users (searching "Snikket" on an app store will get you an app that you know is compatible with your Snikket server, you don't have to go through a list of XMPP clients and figure out which one is suitable).
- Snikket servers are not designed to be open public servers (these are an administrative nightmare). Instead, your server is closed and private by default. As the admin, you choose who signs up to your server by sending invitation links. The invitations also serve to simplify the account setup process - no need to prompt users to "choose a server", etc. They just need to provide a username.
Projects such as Conversations differ by running a single public server (conversations.im) and guiding people to sign up on that server, or choose one of a long list of free public XMPP providers. In some cases that's all what you want. But onboarding a group of people that way is not fun (for example, they all have to share their addresses with the group add each other to their contact lists one-by-one - Snikket makes discovery of contacts within the same server automatic).
Beyond these things, Snikket is all open-source and XMPP. But there is a focus on making a good polished and secure "product", if you like, rather than supporting the entire diverse XMPP ecosystem which includes a range of software of varying quality (weekend projects and more recently, 100% vibe-coded clients). For example, Snikket servers require certain security and authentication features which some older codebases that have fallen far behind modern XMPP standards (think Pidgin, etc.) simply don't support today.
> it’s actually all based on prosody and conversations?
As mentioned, I develop Prosody. I also collaborate with the Conversations developer and other XMPP projects. There's nothing shady here. The goal is just to make a best-in-class XMPP project that solves one particular use case (and it was primarily my own use case to begin with of course - I wanted to move my family off WhatsApp).
And yeah, I get what you are saying, I'm using it the same way you envision snikket, just for my wife and I. Considering how much time I spent on the initial setup, I can very much see wanting a preconfigured version.
I guess the site was just too "non technical" and went over my head when I tried to grok it (before, a while ago, and now before writing the comment), the lack of a download option for the client on the snikket site combined with repeatably talking about invites just rubbed me wrong.
As I have already setup my server, and have gajim/conversations (which afaik are the best modern Windows/Android clients, for Windows probably even the only one storing modern xmpp) for desktop/mobile, I have no need for snikket, but my view now went from negative to very positive ;)
I'm still experimenting with the messaging on the Snikket website. However my general approach with the site was to pitch Snikket to people who don't know what XMPP is, which is, frankly, the majority of people. Instead, I wanted to focus on explaining features it enables rather than protocol details. But I'm aware it has caused a lot of head-scratching among people who already know Snikket uses XMPP :)
I see Snikket as kind of a gateway into the XMPP ecosystem for people who are unfamiliar with it. After all, if you're already familiar with XMPP then the chances are you'll probably be happier with Prosody or ejabberd, and you'll already have opinions about which clients you want to use (e.g. the upstreams of Snikket).
Snikket seems to just be a focus or lens on Prosody that answers that question for the mission statement you gave.
The only caveat I have not been able to solve is hosting an xmpp server for a different domain, like it's possible with email.
A client connecting the account joe.doe@example.ORG will find the server it wants to connect to via SRV to be , e.g., xmpp14.example.COM and expect a TLS certificate for "example.ORG" which that server does not have (nor can/should easily get) - which makes sense in a lot of ways, but limits the ways one can offer hosting services.
If anyone has creative solutions I'm all ears.
Yes, that is of course correct. But that means that your clients have to trust you without technical safeguards, that you will not use this to get for certificates for purposes other than XMPP.
Which, in my mind, is a problem if the domain is not used just for XMPP, but lets say for a website as well.
_xmpp-client._tcp.domain.tld. TTL IN SRV priority weight port target
_xmpps-client._tcp.domain.tld. TTL IN SRV priority weight port target
example:
_xmpp-client._tcp.not-my-domain.com. 3599 IN SRV 5 0 5222 jabber.my-domain.com.
I don't think I have seen a client complain about the cert being for jabber.my-domain.com Which one is giving trouble there?
Probably all of them.
Section 5.4.3.1
> The receiving entity SHOULD choose which certificate to present
> based on the domainpart contained in the 'to' attribute of the
> initial stream header (in essence, this domainpart is
> functionally equivalent to the Server Name Indication defined for
> TLS in [TLS-EXT]).
> Once the identity of the stream peer has been validated, the
> validating entity SHOULD also correlate the validated identity with
> the 'from' address (if any) of the stream header it received from the
> peer. If the two identities do not match, the validating entity
> SHOULD terminate the connection attempt (however, there might be good
> reasons why the identities do not match, as described under
> Section 4.7.1).
But if you serve a certificate for jabber.example.com for a user trying to connect to an account user@example.com using SRV records then that mismatch will give you at least a certificate warning popup. And for good reason too: How would a user verify that a certificate
abcde.1234.jabber.freshhosting.donut
is valid for the account joe.doe@example.com ?
I'm not saying that you shouldn't trust OMEMO (we all have our own threat models), but OMEMO and Signal have fewer similarities that people often assume and has some important caveats [0].
"I'll make an edit later about the protocol version thing, but I'm not interested in having questions answered. My entire horse in this race is for evangelists to f** off and leave me alone. That's it. That's all I want." [censorship of profanity mine]
You won't find this quote in the article with Ctrl+F, it's in the screenshot, where they omitted the original constructive comment by one of the OMEMO contributors that they chose to moderate, which you can find here: https://www.moparisthebest.com/tim-henkes-omemo-response.txt
So, by all means, read the blog post. But just be aware that its ultimate goal was not to be an unbiased accurate technical article.
FWIW, I personally think Henke is correct to state that creating "...a product based on XMPP+OMEMO that, exactly like Signal, can only communicate with other Signal users and always has encryption on." would largely address most of the critiques (or at least the ones that bother me most), but that Soatok is also correct in concluding that the XMPP ecosystem and the way OMEMO is used in clients today does not meet their definition of "Signal competitor"[0], which I think is still a useful way to frame things.
[0] https://soatok.blog/2024/07/31/what-does-it-mean-to-be-a-sig...
Around the same time I tried hosting a Matrix server with Synapse, but quickly stopped. It consumed a lot of resources when doing almost nothing, and it stopped running after an upgrade with some non-obvious error message, so instead of reanimating it I just abandoned it and moved to matrix.org with my personal account.
From my experience the biggest pain point gets the least amount of discussion in this post and that is the client landscape. I'm on iOS so I tried Monal and Siskin IM as my primary mobile clients and Movim/Dino as my desktop clients.
While I truly appreciate the effort the maintainers put into these tools I have to admit that the UX for Moanl and Siskin IM leave a lot to be desired and if you're used to something like Whatsapp or Signal it will prove a significant barrier to convincing friends and family to adopt your new platform.
I frequently encountered UI bugs and missing features using the iOS clients and for the life of me could never get notifications working reliably on mobile (a constant bug bear for users in the Siskin and Snikket user base).
For calls and texts on mobile, I don't think I ever managed to get a reliable notification unless the application was open on the screen on iOS. This meant that I frequently missed important calls or texts when out and about. On the desktop, Dino did manage to at least always alert me when a call or a text came through, but answering the calls on was always hit or miss on my laptop for reasons that allude me.
Interestingly the most full featured and reliable client turned out to be movim, which has the caveat of being a full featured formum/social network with an xmpp client embedded. On movim I would reliably get notifications for calls and texts and could "answer" calls in any browser connected to a microphone easily.
Another thing to note if you're looking to replace your phone service is that 3G/LTE radio is very tolerant to maintaining a reliable connection on the move, jumping between cell towers. The same cannot be said for an XMPP based call, and you will encounter significant latency and drop outs trying to hold a conversation driving or on transit.
I eventually gave up on the venture after missing a few too many important notifications, but if I was to go defiantly go all in again I think I would focus on self hosting a movim instance as my base "client", as it was the most reliable and easy to use of all the ones I tried. For mobile, I did hear good things about Conversations on Android but never got around to trying that one.
There is also a new app in the works between Cheogram and Snikket. There is a beta available, but it's still young (and we won't apply any Snikket branding until E2EE is complete).
Thanks for sharing your experience!
Joining rooms of various FOSS projects has been nice, but honestly I wish they’d all just stick to libera.chat
This article makes me wonder why we collectively ditched xmpp for matrix when it seems like the protocol is still miles ahead?
XMPP puts complexity in extensions (XEPs). The core protocol is simple but you need to cherry-pick which XEPs your server and clients support, leading to fragmentation. Two XMPP clients might support completely different feature sets.
Matrix puts complexity in the protocol itself - the DAG-based event graph for federation is elegant but expensive. Synapse eating your VPS is the direct consequence of that design choice. Every room maintains a full causal history, which is great for consistency guarantees but terrible for resource usage.
The ejabberd comment in this thread is telling - "just works, takes close to no resources, needs almost no maintenance" for almost a decade. That's the XMPP experience when you accept the tradeoffs.
I think we ditched XMPP not because Matrix was technically better, but because Matrix arrived with a better story at the right time: a single reference client (Element) that actually worked, a clear spec (not 400+ optional XEPs), and federation that felt more like email than like "hope your server supports the same extensions."
The irony is that both protocols now face the same existential problem: your contacts won't switch. The network effects of WhatsApp/Signal/iMessage are the real enemy, not protocol design.
This is of course true of Matrix as well. Just because you document everything in one place doesn't mean every app will support it all. Or that every app will even want to support it all. If every app were exactly the same there would be no point in having multiple apps, after all.
> The network effects of WhatsApp/Signal/iMessage are the real enemy, not protocol design.
Absolutely.
The servers (ejabberd included) also all defaulted to a simpler but less secure config, so I would've appreciated a writeup like this post back then.
Edit: Seems someone beat me to it with a good reply.
I.e. it worked too well.
We didn't. It was never very popular, and is today more popular that it has ever been.
Not sure how popular the small federation was back then, but I know Mac OS X Server touted an XMPP server and that was a first-class feature of iChat.
I remember this, it was great to connect to absolutely every chat platform with bitlbee and pretend that all my chats were just DMs on some irc server somewhere
I haven’t had a reason to use an xmpp client in over a decade.
Even today, E2EE in XMPP is rather inconvenient compared to Matrix due to absence of chain-of-trust in key management.
Facebook Messenger support for XMPP: 2010-2015
Jabber.org support for new accounts: 1999-2013
First-class integration with two of the world's largest social networks put XMPP in practically everyone's hands for a time, but when all the major hosts left, network discoverability and typical account longevity dropped drastically. The landscape is bleak today.
And since then, our collective needs and expectations of a chat platform have expanded. XEPs have been developed to bolt much of that functionality onto the base protocol, but that has led to a fragmentation problem on top of the bleak server landscape.
This unfortunate situation might be navigable by a typical HN user, and perhaps we could guide a few friends and family members and promise to keep a server running for them, but I think the chances of most people succeeding with it are pretty slim today.
In any case, it contributed significantly to XMPP's reach and utility, and it's gone now.
* SMS * Apple iMessage * Email * IRC * Facebook Messenger * Telegram * Slack * Webex Teams * Discord * Twitter (DMs) * Signal * Whatsapp * A particular PHPBB web forum
Instead of being on top of all of these, I mostly neglect all of them, and then friends complain that they haven't been able to get a hold of me for 6 months.
XMPP was my own "solution" to this problem, which nobody else used.
Sad because the idea of running a federated chat service for your family and them having all their contacts there, is great from a data ownership point of view.
Went back to use a mix of WhatsApp, Telegram, Signal and Messenger because apparently there is always some people not wanting to use one or the other service, or only using one of them.
That's exactly what XMPP was created to solve, an open standard that could be implemented by anyone. For a while it even looked like there was a chance for that to work out. Whatsapp, Google Talk, Cisco Jabber, and some others used to be based on XMPP.
Unfortunately it didn't quite pan out that way.
WhatsApp OTOH still is a fork of XMPP.
So self-hosting federated instances like this is pretty interesting way to scale.
> But Signal is still one company running one service. If they shut down tomorrow or change direction, I’m back to square one.
Aren't they in the same boat now with Cloudflare and Let's Encrypt?
Also if we go down this road, we’re all depending on our internet access provider at the very least too! At some point we gotta know when to stop trying to be fully independent from the rest of the world. He chose there.
That would certainly be a very annoying event, but not an unrecoverable one.
Also plugin for gif selector.
But other than that, my ejabberd instance has been running for years with no effort.
I've been using Dino on Linux to talk to Conversations/Monal with video and it's been working pretty well. Do you have a different experience ?
One thing I'd add: if you're already running Caddy as your reverse proxy, you can use its on_demand TLS to handle certificates for the upload and conference subdomains automatically instead of managing them through certbot separately. Saves a moving part.
Curious how federation has been in practice. Are you actually messaging people on other servers, or is it mostly just you and contacts you've created accounts for?
The experience was unpleasant in both cases; in the end, I have a working setup for both, relatively working at least, but what's really missing is a single application, something you can 'go install', 'pip install', or 'cargo build', also easy for distro packagers, that features:
- a text-based configuration
- an admin WebUI (for eventual storage cleanup, moderation etc)
- a client WebUI for users
including:
- text chat with optional file uploads
- audio/video chat
- other bits on the side like long-form notes Nostr-style for a blog with comments under articles etc (yes, it's connected, it's just plain textual communication).
The core of it is just a simple snippet of text, we can transmit to some privately, or to anyone openly, and in that sense, Nostr has got it spot on: you can do chats, emails, blog posts, because everything is just a bit of text rendered with any attached media. Unfortunately, as it stands, Nostr feels like an ecosystem that lacks a clear direction; XMPP seems to be largely abandoned, with enough complexity to put most people off; Matrix looks to be heading towards a commercial future riddled with issues that keep most people away, and in the end, we don't have much. Hosting BBB or Jitsi is even worse. Hosting Asterisk or Yate to use with softphones or classic VoIP desk phones is also problematic.
There's a lot going on under the bonnet now, but why an app hasn't emerged yet that brings together features we've more or less had for decades is a bit of a mystery to me. It almost feels intentional, as if it's designed to deny free communication to the masses by making life difficult on purpose.