Hacker News new | past | comments | ask | show | jobs | submit login
Modern XMPP Server (trueelena.org)
89 points by JNRowe on Dec 2, 2023 | hide | past | favorite | 60 comments



XMPP could have been something truly great. The ejabberd project alone has been used to build WhatsApp, Nintendo's Push Notification System, Epic Games' Chat, etc. - so it does have a genuine track record of being scalable and providing value to this day.

I suspect the thing that held back its adoption for end-users (or is still holding it back) is the fragmented ecosystem and so-so open source clients with questionable inter-compatibility, i.e. you can get calls from Windows to Android to work as an end-user, but it's a rocky path.

Hopefully we can one day see the great XMPP renaissance.


Like with so many mainstream usecase projects, I'd wager to say the protocol/backend is the easy part. It all depends on good easy to use clients.


> I'd wager to say the protocol/backend is the easy part.

And yet, in 2016, 9 years after the first iPhone, XMPP still struggled to provide any of the modern conveniences on the protocol level: https://gultsch.de/xmpp_2016.html (at the time most of the links marked as "solution available" were going to experimental and beta proposals)

The protocol/backend can be, and often is, as much hindrance as the clients.


iOS is not indie-dev-that-does-not-want-to-monetize-friendly and I believe this is the cause of this struggle. Siskin and Monal are iOS clients that solved the issue apparently.


> indie-dev-that-does-not-want-to-monetize-friendly

Noting is "I need to spend a significunt chunk of my time for no renumeration"-friendly.

And yet there are numerous free, or pay-less-than-a-cup-of-coffee clients for many things and services, whether those are open or closed, free or paid (Ivory for Mastodon https://tapbots.com/ivory/ and Wikipedia's app come to mind).

Thanks for the tip for Siskin and Monal! Even a few years ago the situation was dire.


> Nothing is ...

Fair point. I'm a dreamer ;)

I believe the lack of great clients for apple platforms is due to how little the overlap is between people who see value in using a self-hosted, federated, lightweight chat system and people who want to use apple products.


thou afaik the spec does not include any provisions for direct messages (as technically it's only a group with two members), leaving the mess up to the clients.


Where are you getting this? My memory is the exact opposite: XMPP targeted one-to-one messages first and then MUC was a sort of weird bolt-on.


apologies, my memory must have gotten mixed up.

point stands, as both deliver a subpar experience with either dm's or groups


That's true for Matrix, not XMPP.


Why could have? It is truly great. I've been running a server for my family for two years now and it has been pretty solid. If I show my friends how to get an XMPP address I also recommend them a modern client (Android: Conversations from F-Droid, iOS: Monal).

I feel like compatibility between clients is good, people just aren't used to having independent implementations anymore. It's easy to cook up your own protocol and have compatibility by being the only game in town but if you look at the bigger picture you have just created more fragmentation. We need more instant messaging standardization and XMPP serves an important role as the IETF internet standard for IM.


I've tried occasionally hosting XMPP servers for a long time and sadly I didn't have as nice of an experience client-wise as you did. Especially on Windows, where most people live, the biggest clients don't properly support video or even voice calling and OMEMO support used to be really hit or miss in a way where depending on the person I was texting I had to switch to OTR. (This is, admittedly, way better now)

Maybe the modern web-based clients like Movim are better, never got around to testing them. I'll admit that Android always was the golden platform for XMPP thanks to Conversations - as long as you stick to that on both ends it's the perfect experience.


It is sad indeed that the development of clients relies on the volunteer work of a very limited group of individuals, mostly explainable by the lack of "hype" around Jabber/XMPP.

FWIW it's been smooth-sailing for me and my non-tech family and friends for many years now. BTW, OTR is deprecated, and OMEMO just works.

This project looks promising too: https://prose.org/

> Windows, where most people live

Most people live on their smartphone for IM these days, at least in my circles. I have been surprised by how few people are actually interested in getting a chat app on their "real computer".


I think many people don't even realize how inter-device their IM service usage really is due to how seamless the web frontends of WhatsApp/Telegram/etc. are. Some people like to use these when working on their desktop for 8+ hours a day.


I don't witness this around me. By far, most of my "real life contacts" will only use their phone to use messaging apps, and don't use whatsapp web at all.


Since we're recommending clients, Quicksy (basically the same as Conversations) is great on Android to be close to the UX of Whatsapp, Telegram and Signal (your ID=your phone number + autodiscovery of contacts). I don't want it for myself (phone number as ID? yuk), but I think it's underrated as it seems to fit what a lot of non-techies actually want.


Both Conversations and Monal are abysmal from modern UI/UX standpoint and don’t get even close to something like Whatsapp or Telegram (and those two have lots to improve themselves) Same can be said about desktop clients.


Time was when Google and Facebook both used XMPP (I think with official cross network support in their apps?). I also recall MSN Messenger being able to talk to Yahoo Messenger, though I'm not sure if they used XMPP for that.


Google talk was XMPP-federated for a while (but never upgraded to good practice such as using basic encryption...), and while you could connect to Messenger via an XMPP client, they never enabled federation.


Shameless plug: once prosody is up and running, add some gateway components to use your xmpp clients to chat with those still jailed in walled gardens such as WhatsApp, telegram, signal, discord (and a few other more): https://slidge.im


I've been running slidge to bridge WhatsApp for a while now and it works great.


Any decade now people are going to realize how awesome XMPP is and start using it for everything!


I've heard 2024 will be the year of the Linux desktop and XMPP...


Not sure about _everything_ but it is already in use for notifications on Nintendo Switch, Fortnite group chats, WhatsApp... Of course, none of these are federated or mention XMPP anywhere, but it tells something about the intrinsic qualities of the tech IMHO.

https://xmpp.org/uses/instant-messaging/

https://xmpp.org/uses/gaming/


WhatsApp will be forced to federate as a designated gatekeeper under the DMA by the EU. XMPP could be an obvious choice to them since they already use it internally.


They use private custom extensions that makes it non-trivial to federate with XMPP unfortunately. I haven't followed closely what's happening with this DMA but I wouldn't get my hopes up about XMPP being chosen for anything, sadly.


> Any decade now people are going to realize how awesome XMPP

In all honesty, it's not that awesome. It took XMPP over a decade to get features expected from modern protocols such as not requiring persistent connections, client notifications, conversation syncing between clients, file uploads, E2EE...


How many protocols do you know that made that transition at all? I don't know many that even have that level of requirements (low latency, multi-device, low energy consumption, federation, scalability) in the first place, and even fewer that managed to pull that feat off.

IRC probably has a similar level of requirements, but I haven't heard of its mobile capabilities. Most others seem to be completely new developments and in the case of Matrix e.g. they seem to have solved some issues by reducing the scalability (higher server load).

So yes, it took a while for XMPP to solve those issues, and you can say it took too long. But at the same time having done that at all, is an achievement in itself.


If you account for resources which have been put into development of those features, it's pretty obvious XMPP is the more agile protocol. Five independent open source developers take longer to develop some feature in their spare time than a corporation with tens of millions of venture capital funding, and sometimes they're even faster? Imagine what could be if people focused on XMPP instead of constantly re-inventing the wheel.


> If you account for resources which have been put into development of those features, it's pretty obvious XMPP is the more agile protocol.

10 years is not agile.

> Imagine what could be if people focused on XMPP instead of constantly re-inventing the wheel.

We could try and imagine. As it stands, it's XMPP which is reinventing the wheel, continuously. The primary reason being: it was developed at a time when non-persistent internet connection, multi-device synchronisation, video calls, ubiquitous file sharing and other wonders of the modern world didn't exist, and retrofitting it was a multi-year struggle. Undoubtedly prolonged by the very same people who decried the modern world and claimed that XMPP was enough: https://news.ycombinator.com/item?id=38497839


Do not trust the FUD.

I've been using XMPP since I had a smartphone (I was late to the party, around 2015) and never needed a persistent connection or had issues with multi-device use. https://xmpp.org/extensions/xep-0313.html solves both and the first version is from 2012.

E2EE via opengpg has been there since the beginning of XMPP, and via OMEMO (signal-like) for 7 years now, just like HTTP file upload.


> Do not trust the FUD.

I don't. I know what I'm talking about: https://news.ycombinator.com/item?id=38497839

> solves both and the first version is from 2012.

The question is: when it stopped being experimental and supported by most servers and clients.


You saying things like "experimental or beta proposal" in context of XEPs shows that you don't know what you're talking about. For a while and for several reasons, many XEPs used to be widely implemented already before they have been processed beyond draft state. XSF's process has been unclogged relatively recently.


most consumer devices and services nowadays build upon foss tech, some even could be used in a foss way, but walled gardens are so much more profitable.


True :)


Looks good. A couple more things I find useful to set with Prosody are:

- The firewall module to blacklist spammers; that can be done with a system-wide firewall as well, but it is nicer for diagnostics to serve proper errors, not just to drop packets or refuse connections.

- The bosh and websocket modules, to use with converse.js. A web UI is convenient to have for logging in from systems without XMPP clients.


I never needed to set up firewall to fight spam, but maybe I was just lucky. I think https://xmppbl.org/ via https://modules.prosody.im/mod_muc_rtbl is the way to go to fight spam if you plan on hosting public groups.


Now we need a decent client :-( Ideally, something with UX level of Telegram.



Avoid this shady app. Some years ago the developer removed OTR support without warning then casually claimed the app "never did any verification" without additional clarification. This is a dangeous attitude for someone responsible for developing privacy-minded software.


OMEMO has replaced OTR. Conversations.im supports OMEMO.

Conversations.im and its developer produce great things for the community:

* Conversations.im itself

* https://snikket.org/open-source/ and https://quicksy.im/ are built on the conversations app

* Hosted XMPP: https://account.conversations.im/

* Compliance testing: https://compliance.conversations.im/


None of that addresses the concern about the developer's attitude and shady statement about OTR straight up not working in his software. Maybe he's done other good things for the community, but having unreliable crypto is a deal-breaker for me.


OTR is now dangerously insecure:

https://dustri.org/b/time-to-sunset-otr.html


I feel the Android clients are quite usable. But, for some reason, the iOS clients seem to be less well developed.


Is this “because I can” or does XMPP fill a niche in modern text chat? This feels like a step beyond running your own email server.


XMPP fills the very important "simple, and gets the job done" niche in this space. I was looking into options for a self-hosted chat service for team development about a year ago, and landed on XMPP. -- I'm happy to entertain suggestions, if I've missed anything, but I don't want any cloud service, and mattermost is bloated as hell.


Well, it doesn't fill anything but was there before XYZ came. Matrix has mostly the same properties (open source, federated). Signal is not federated and WhatApps is neither federated nor open source (but has the most users).

The things that make XMPP unique are very superficial. For a long time, it was the dominant IETF Standard for instant messaging and it has proven that it can adapt to new circumstances (mobile clients), but who cares about such stuff nowadays ;-)

Compared to running your own email server, you just have to solve different problems:

- XMPP has higher uptime requirements (from a user perspective)

- spam is not such a big problem for small installations


Compared to Matrix,

- Much lighter in processing and storage requirements (at the cost of group conversation history being a crapshoot)

- Not de facto controlled by New Vector, which I’m gradually losing faith in[1][2]

[1] https://news.ycombinator.com/item?id=38162275

[2] https://news.ycombinator.com/item?id=38451920


I might be biased, but I self-host both XMPP and email, and XMPP is easier. Roughly equivalent in resource usage for a small private server.

Snikket (a project I started) is probably the easiest way to get a modern XMPP setup these days, or (if you're more into system packages than docker) it's pretty straightforward to get up and running with Prosody, this guide being a good indication of the few things to think about beyond "apt install prosody".


> Is this “because I can” or does XMPP fill a niche in modern text chat?

Not only text chat, but also audio/video calls, file transfer. And not sure if it is exactly a "niche", but it is a standard for a federated IM, quite widely supported. Probably the only comparable alternative now is Matrix, but that comes with a bunch of downsides.

> This feels like a step beyond running your own email server.

Running both XMPP and mail servers, I find that an XMPP server setup is easier: there are fewer components, less spam, fewer restrictions on federation; I think you can run it fine even with a residential ISP unless there is a NAT. Not that email setup is particularly hard though.


Hosted secure chat is still a very important niche. Matrix.org is failing so far once you add many users. XMPP fails too, usually, but for different reasons (configuration issues hard to debug, apparrently).


Why the main domain https://www.trueelena.org/ looks that ugly?


I think ugly is the wrong word. It looks old.

20 years ago many websites looked exactly like that. Hand-written (<!-- vim: set filetype=rst: -->) and just with basic CSS formatting.


A honest-to-God personal website. So refreshing.


Because it is no longer updated, it says so on the top.


Well yeah, but it is the main domain. It is like a front door isn't? Shouldnt it be kept updated?


I can't wait until my front door needs regular updates to keep working


Is that comment supposed to be useful?

You need to make updates to your front door. You need to make updates, repairs, clean it. So yes, front doors require updates.


Listen here you little shit.

There are doors that have been in continuous use for over a thousand years (like St. Botolph's Daneskin door).

Comments don't have to be useful to be good, but updates do.


Is your comment suppose to be useful?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: