Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I think the article brushes over something that adds (IMO) a ton of friction to Jabber/XMPP: self-hosting your own server. About 6 months ago, I tried to go down the awesome selfhosted XMPP servers list and it was just so painful I ended up finding an alternative stack.
  • What stack did you land on?
  • Snikket claims to solve this but assumes it's got a routable IP address. If you've got it on a VM somewhere cloudy you're probably fine but I had to really jump through hoops to get it working behind NAT on my own hardware.
  • I just went with Prosody and it took maybe 20 minutes with claude+opentofu+docker to get it added to my stack.

    It _works_, but the limitations of Jabber without 42 different optional extensions became apparent pretty quickly.

  • I'm just a hobbyist sysadmin, but I did get a ton of exposure over the decades deploying some pretty random stuff, often taking the long and painful way as a learning experience (rarely using containers, often compiling from source, …). I vividly remember deploying ejabberd for the first time in disbelief: for all it was doing, it was just a fire and forget/good defaults/good logging/self-healing experience. Highly recommend.
    by ezst
  • Same! I tried to make a server using a tutorial from the HN popular page recently, and it wasn't working. I'd done it a decade ago but not in a public-facing way, just local IP addresses and no TLS.
  • On the contrary I found hosting an xmpp server extremely easy and very light in maintenance with prosody. I've been doing it for years and it's the part of my infrastructure that I spend the least time on certainly.
  • Jabber/XMPP is now over 25 years old. Its peak was back when Google Talk and Facebook Chat adopted it in the late 2000s and when Whatsapp launched using XMPP under the hood. And it largely died when those two large companies went fully proprietary around 2015.

    The fact that 25 years later it's still being described as two completely different names with a slash between them ("Jabber" SLASH "XMPP" ) makes me pretty confident it's not coming back.

    Don't get me wrong...I'd love open, interoperable chat that everyone is reachable by as much as anyone, but it's important to recognize when one approach isn't working and why it isn't.

    There's a lot of lessons to be learned from the death of jabber which I outlined in a post back on 2019: https://larrysalibra.com/the-death-of-jabber/

  • It doesn't matter as much as you think. Office workers around the world are using email(/IMAP) just fine. Jabber/XMPP was used today to the satisfaction of everyone when I video-called my 90 years-old relative. All she had to do was to scan some QRCode a decade or so ago when I on-boarded her. XMPP isn't going anywhere. As I wrote in a sibling post, it survived 2 or 3 generations of commercial messengers, and only got better and more relevant in that timespan. It's far from dead. I'll probably be dead myself long before it does.
    by ezst
  • I think the main problem was the fragmentation & extensions
  • There’s no official way to “tag” people on Jabber. Clients do it but the protocol doesn’t.

    This is (to me) a big issue when using bots, for example. I need a non-ambiguous trigger for them.

  • There is a XEP for it but as per usual, it's experimental and not widely implemented: https://xmpp.org/extensions/xep-0513.html

    https://xmpp.org/software/?category=clients&xeps=0513

  • traction? the xmpp moment was 20 years ago. it's over now
  • The software playing field is different with AI. Like making nice mobile/desktop apps used to be a serious barrier.
  • So was RCS, until Google resurrected its rotting corpse and made it the default messenger for billions.

    All we need is for a billion dollar company to build their own implementation and XMPP can be back once more. Exactly the way it gained popularity back in the day.

  • Yep. He's dead, Jim.

    If reviving XMPP is the battle you want to fight, best of luck but I'd encourage you to take a step back, face reality, and spend your energy on something with a better chance of success. And I say that as someone who used Jabber all day long 20 years ago.

  • I remember when I connected my XMPP client, Pidgin I think, to the Facebook XMPP server and all my Facebook "friends" appeared in Pidgin as chat contacts. That were the times. Eventually Facebook turned this possibility off...

    Probably the Facebook chat is still XMPP internally even today.

  • At some point I had iChat with AIM, Facebook, and Google all set up, and actually talking to all my friends that way. It was sweet.
  • by ezst
  • I'd like Jabber to establish itself as the federated, non-E2EE chat platform. OMEMO is too little too late. You want E2EE so badly, you use Signal which has figured it out better than anyone else and is still glitchy. There's a reason Telegram is more popular; most people take stability and features over security.

    Some use cases like business chat actually can't have E2EE, and that'd probably be Jabber's foot in the door because no other open solution has taken off in business, and businesses don't need so much network effect. This was a main Jabber use case back in the day too.

    Make decent official Jabber clients, called Jabber and not something else like a bird, and server that implements the right spec with default settings. Now is the time, you can AI slopcode entire native apps if you want to. If someone really want to put extensions on a server, it's called XMPP and isn't compatible with Jabber; the X stands for excommunicated.

  • > Some use cases like business chat actually can't have E2EE, and that'd probably be Jabber's foot in the door because no other open solution has taken off in business

    So, Cisco Jabber (now Webex)? You can't really compete against Microsoft and its bundling strategy. Even Slack is dying, unfortunately.

    by ezst
  • > There are only two features people actually care about: reliable message delivery and the ability to reach their friends.

    Sorry to be a pain, and with full recognition that I don't probably represent the majority, but I care about emoji reactions, reply support, ability to send & receive images and video, ability to see that video later, a reasonable set of access control features for group chats; reply-privately for group chat messages, and a dozen other things. And I care about not making someone download an app I've never used that talks the protocol, because I can't support them getting started. So a single cross platform UX is needed too before you can hope for traction.

    Some of this is UX; some requires infra (eg. storing & forwarding media)

    But to produce a "complete" messaging tool is harder than it looks and the protocol layer, while important, should not be the focus of discussion. There needs to be a holistic conversation that includes UX, infrastructure capabilities, branding, and network effects.

  • Yep, the baseline for "messaging" has changed. Without first party emoji support, preferably custom emojis too, images, reaction gifs etc the majority of non old-nerd people won't even consider the system.

    And it can't just be an optional feature in some clients, it needs to be something that just works everywhere.

  • I use XMPP (with OMEMO) extensively and my main problem with it is absence of some basic key trust chains and bad handling of group chats

    1) With OMEMO, each client/device of a user has its own key, but there is no trust relationship between them or some common master key. I can verify and trust counterparty key, but then counterparty adds another client/device and i have to do manual verification again.

    2) Group chats do not have group key, but one encrypt messages for each group member (pairwise), which means that everybody has to do key exchange with everybody. This does not scale, especially with 1), which means that even if membership is stable, new keys may appear. Some clients (Conversations) do not allow to send message to a group when they do not know some keys of some group members/devices, which is fail situation that happen pretty often.

  • I've tried designing an E2EE group chat system before and ran into all of these. They're not impossible to solve but are very hard. Telegram's official docs shrug off multi-device E2EE too, calling it a "mess."
  • 1) I think that's by design: you've got two ways to use OMEMO, the "friendly (default)-way" (with BTBV, Blind Trust Before Verification), and the "paranoid-way" (where you verify each and every device). In the latter, you don't want your messages to be encrypted for a new, unverified device (as it could potentially be that of an attacker): you can either verify the new device yourself, or your contact can verify theirs and you verify them again. Like I said, that's not for everyone. And if you are not that paranoid, then verification is an afterthought anyway and you don't lose or gain much with verification anyway.

    2) That's where MLS¹ kicks in, essentially a new encryption scheme that's suitable for large group chats. There are projects² for its adoption in XMPP. I have no strong opinion about MLS, but I tend to think that it's more for the gimmick and having XMPP score well in random protocol benchmarks: if you've got such a large groupchat that OMEMO doesn't scale anymore, you have a groupchat with so many participants that it is only private in name and more or less encryption doesn't matter.

    ¹: https://en.wikipedia.org/wiki/Messaging_Layer_Security

    ²: https://nlnet.nl/project/XMPP-MLS/

    by ezst
  • I hope more people realize, protocol is not the problem, user experience is.

    The Telegram client leads in every aspect by far. It's just easy to use.

    by est
  • As long as the Signal desktop app is a 420 MB[1] pile of Electron, I refuse to install it. I may be a dinosaur, but a good desktop app is a requirement. I hate typing on a touch screen.

      [1] $ curl -s https://updates.signal.org/desktop/apt/dists/xenial/main/binary-amd64/Packages |
        awk '/^Package: signal-desktop$/{p=1} p{print} /^$/{if(p) exit}'
  • I'm really surprised that nobody bothered making a fork of the Telegram open source client that works with XMPP.
  • >The Telegram client leads in every aspect by far. It's just easy to use.

    Frankly speaking, Telegram is also shit. It just sucks a bit less than the rest of them.