I'm still looking for the (mostly) perfect self-hosted chat solution, and I find the search increasingly frustrating.
I used to run both an XMPP and a Matrix / Synapse server; I've dumped both. A couple of days ago I tried both
Rocket.chat and
Mattermost and ditched those, too. I would like to share some of my experience here.
XMPP
XMPP still has issues with offline messaging. Text messages are less of a problem, but sending files of any kind
is. In theory, this is supposed to fixed with
XEP-0363: HTTP File Upload. From a practical view, I ran into two issues in my most recent testing.
Firstly, file upload appear to happen over unencrypted HTTP using port 5280. I haven't figured out yet if it's possible to change that to HTTPS, or if this is something that happens on the client level; I suspect the latter.
The second problem is more severe. Apparently, what happens when using http_upload while the receiving party is offline, it doesn't get sent the picture (or whatever) when it comes back online but a
link to the file. There are issues with this, especially in combination with OMEMO.
I tested with two phones and my desktop. On the desktop I used
Dino (which admittedly is still in a very early phase) and PSI+. I settled on those two because they support OMEMO. In theory, so does Gajim, but the version currently in the Ubuntu 19.10 repositories seems to be buggy; it won't let me activate the plugin, and I didn't have time to look into this yet. On the two phones I used
Conversations (which is without a doubt the most stable and easy to use XMPP client for Android right now) and
atalk, which I tested because of its support for
Jingle voice and video calls (which work really nicely, by the way.)
The only client where sending files to offline contacts worked a hundred percent as expected was Conversations. After you log in, there is a download button; you tap on it, and the file will be downloaded within the current conversation. This is important in connection with OMEMO. Every other client got a link in the form of
http://server:5280/upload/somelongrandomstring. The link opens in an external browser, where it can't be decrypted.
The other problem I have with XMPP is multiple device support. Yes, it's possible to send OMEMO messages to different devices, so encryption is not the issue in this case.
History is. Picking up a conversation that started on mobile on the desktop does not work as flawlessly as it does with other services that support multiple devices.
I think a great deal of the problem stems from the fact that XMPP is so old. Back then, people where using IMs when both parties where online, and they were probably using the same computer all the time (or maybe two if they were using computers at work.) It's probably not that easy to make it conform to modern expectations. (And now that I'm writing this I'm wondering if that influenced the name of the Dino client...)
Matrix/Synapse
From the client end (Riot), Matrix works great. It works on multiple devices, even with E2EE; offline messaging, including file transfer, works flawlessly.
That being said, it's still not the right thing for me (as in: for me
personally.)
One of the issues I have with Matrix is that it's not possible to delete rooms from the client. Yes, I'm aware that there's a
way for the server admin to purge old messages, but a) it relies on the admin to do so instead of giving the user control over their own messages, and b) it requires some technical skill that is still beyond me.
I'm also not very comfortable with PostgreSQL; I'm barely comfortable with MySQL, and least there's a web frontend for it that's easy to install, configure, and use.
Another thing is that I never managed to set up federated voice and video calls, which requires a TURN server. That is one thing I like about XMPP; it doesn't rely on the server to provide the functionality but instead uses peer-to-peer technology which needs to be implemented by the client. Unfortunately, so far I've found only the one that does, the aforementioned aTalk.
Lastly, the state of the documentation at this point is not one of its more endearing characteristics.
As I stated in the beginning of this section, all of this is personal. I'm not an IT professional; I consider myself more of an advanced user. There is too much about Synapse that requires more than basic understanding in other areas; understanding that I don't have and I'm unwilling to donate exorbitant amounts of time to just to set up a chat server that in all probability I'll have trouble to convince anybody to switch to.
Rocket.Chat
Rocket.Chat has one thing in its favor: its ease of installation. Under Ubuntu, it installs as a snap. Documentation is excellent. I had no problems whatsoever to set it up and connect both desktop and mobile apps. It has a very nice configuration backend, where every aspect is configurable through point-and-click. I really like that. It's not that I'm not comfortable using command line tools, but they do require a lot more involvement. Like I said, advanced user, not professional sysadmin.
I have some reservations about NodeJS; I admit that this is probably due to the fact that I'm not a developer and I don't know the details of how it works. It does seem to me, though, that relying on a remote code repository to complete your own code is a bit risky. Yes, if the remote code is Open Source you can verify it. But you'd have to do that every time it gets updated, and as a user, I'd have to trust the developer to actually do that.
I'm also not entirely sure about their implementation of E2EE. When I enabled encryption for a room, a password phrase was auto-generated. On a new client, in order to decrypt the room, you're supposed to put in said phrase. On the mobile client, however, the messages just showed up without asking for the password. The room was now "read-only". This seems a little fishy to me.
What put me off in the end, though, was the mobile situation. There is a client on F-Droid, which is what made me aware of Rocket.Chat in the first place. But
according to the GitHub page, it's no longer being maintained. They switched to React Native, and the new client is no longer available outside of Google Play. And even the old client, when installed from F-Droid, was missing a very basic feature: notifications. I'm aware that actual push notifications require the Google apps. But there are ways around that. Signal, Telegram, Conversations, all solve this problem by providing a foreground notification. Threema solves it with background polls. Yes, all those methods use more battery power, but I can live with that if it preserves my privacy and
still get notifications. And this is on top of the aforementioned encryption issue. So I ditched everything and went searching again.
Mattermost
After my Rocket.Chat experiment, I tried Mattermost. Very shortly. I have absolutely
nothing to say in its favor.
You can create but not delete teams. There is no encryption. Configuration, while possible via a web frontend, is not intuitive. The mobile client suffers the same notification problem mentioned in the Rocket.Chat section. So no. I'm not even going to look at that again.
Alternatives
NextCloud Talk
NextCloud Talk is something that I'm keeping an eye on, since I already have a NextCloud instance. There are still two issues that would need to be resolved in order to make it attractive to me: Notifications on mobile without Google Play (again), and federated calls. But since it doesn't cost me any extra work or resources to keep it around, I will continue to do so and hope that things will change.
Peer-to-peer messaging
This would be what I would consider an ideal solution. Forget central servers and let devices communicate directly. No need to trust a central server at all.
I know of three different implementations of the concept.
- Briar (link)
Based on all my experimenting I consider this the most stable at the moment. There are features that haven't been implemented and which I really miss, but what has been implemented works as advertised. I would like to see at least profile pictures and file transfer before I try switching my friends, but it does seem to be under active development.
- Tox Tox
I'm using qTox on the desktop, but development on the Android app appears to have stalled. Which is a bummer, because there is one thing about it that really bugs the hell out of me - every keyboard app I tried it with stays on caps lock. I consider this a deal killer.
- Jami (link)
This looks very promising, but I did notice some issues during my test that would make it unsuitable as a recommendation to my non-techie friends. While it's possible to connect multiple devices to the same identity, history doesn't get transferred, and it doesn't always work smoothly. Also, I noticed, that the contact's name and picture doesn't get transferred until after the first call - messaging alone won't do. I also ran into problems sending files. Voice and video works really well, though; this should probably not be a surprise since Jami developed out of a phone application for Linux.
At this point I'm not sure any of those three are ready for prime time.
Conclusion
I'm looking at this situation in terms of a) "Could I convince my non-techie friends to use this?" and b) "Is this something I'm comfortable running on my server?" At this point, there isn't anything that fits those criteria, which is what makes it so frustrating.
The one I have the most hopes for is certainly Matrix. It was designed with modern requirements in mind, so there aren't too many contortions required to get things like E2EE, multi-device usage, offline messages, and voice and video calls to work for everybody. Also, I recently stumbled over
plans to remove the need for a central server, and
that is something I would be very interested to see happening.
One thing that is absolutely crucial in my view is ease of use. If we want to have a system that is widely adopted it needs to be usable by people who don't stand on the firmest of grounds when it comes to technology. This is what made WhatsApp such a success - install the app, put in your phone number, which all your friends already have anyway, and start messaging.
