Also a self-hosted server with opinionated defaults. The year is 2026, and most users expect persistent history without having to add mod_mam themselves. Discord won from zero because it's IRC with history. I cannot believe that chat history, mentions, etc. is still not settled.

> People don't really sign up for protocols, they download apps.

This is both true and also if followed would fly in the face of what XMPP (and the Mastodon-flavored ActivityPub-powered fediverse of microblogs-and-more) is supposed to be about. And it's also both true and yet people understand what "email" means and how to use it without constantly and consistently running into issues trying to bang out a reply to alice@gmail.example even when the sender's inbox is hosted @yahoo.com—nor do folks spend much time thinking about how and why AT&T's SMSes (for example) are able to make their way to their friend's device even though they use Verizon (to give another example—and if they even know which provider their friend uses at all).

One thing that Jabber (and, later, Mastodon) did wrong was to take the unfortunate stance that it wouldn't be too big of a deal to adopt email-like identifiers without actually being email or implying that Internet-standard email services are available; it was felt that users would just be smart enough to adapt to it. This was a mistake.

The confusion with email, though, can be exploited as useful momentum—something that the network has going for it, instead of a flaw.

If the author and the rest of the Jabber/XMPP community wants the public to "give Jabber/XMPP a shot", then it probably does need (a) a flagship instance (a la mastodon.social) that controls multiple domains (the way that many email providers like Runbox or Fastmail do) and requires the user to pick which one they want their handle to be associated with at signup, in order to introduce email-like decentralization to the userbase as early as possible, and that (b) raises the bar by setting a standard among Jabber/XMPP instances and actually offering email services to that userbase (prior art: Google married (XMPP-based) Gtalk with Gmail in the early days).

While undertaking all of this, an effort to update the XMPP protocol (a la JMAP, but in a backwards-compatible way) while simultaneously reconciling it with legacy email (also in a backwards-compatible way) wouldn't hurt—where "backwards-compatible" here means "to gracefully degrade and provide a fallback" (prior art: Delta Chat).

Mastodon too has several client (web)apps. The Fediverse is itself a more neutral protocol with more heterogeneous platforms based on it (e.g. Lemmy, Pixelfed, etc), so Mastodon refers more to the platform (schema, UX, wider community) than the individual UI you use to access it, which just happens to usually be whatever your instance admin serves by default.

As for apps, people simply prefer instant messengers purposefully designed for their platform. There is genuinely a lot of platform-specific quirks around things like push notifications, which a non-iPhone developer not have the motivation to figure out. Besides that, a lot of these predate contemporary cross-platform technologies like Flutter.

Something like https://en.wikipedia.org/wiki/Pidgin_(software) ?

There are too many XEPs. Would have to cut stuff. Also, there's one humorous XEP about switching to JSON that I actually want :)

>If you tell people "on Android you should use this app, on iOS use that app" - you lose regular people fast.

People don't use single browser and single email client, why IM should be different? It's a deficiency when you're forced to use a single "official client".

That was the biggest issue since the beginning - the mix and mash of supported features just meant nothing just worked - like sending files might work depending on which contact you send it to, which is experience nobody wants.

It just needs feature versions - you support this one, means you support all of the features deemed important for users, no partial mishmash.

It doesn’t appear to be honestly asking.

It’s mostly whining that the world is too unfair because capitalism and people are dumb for choosing Signal, etc.

^^ this guy gets it!

XMPP has brilliant session management, it reconnects more seamlessly than many other protocols on mobile. It literally reconnects (rejoins the same session within different TCP connection, not replaces it with a new session).

>Also sending media (or even rich text) never really worked as each client implemented it differently.

Everyone use HTTP upload nowadays, it works all the time.

I have no problem with that with XMPP. Conversations automatically reconnects after each switch within few seconds, so it is transparent for users. On IRC that is huge pain, true.

XMPP is more reliable than Signal on iOS. My wife regularly doesn't get Signal notifications for messages that I sent when she was in a marginal service until hours later when she opens the Signal app to send me something.

On Android, I've never had any connection issues with either Signal or XMPP, so I would say that this problem is solved.

So, my understanding is that while XMPP has historically sucked on mobile, it's gotten better? Does anyone know about the current experience? I don't know if it's due to new XEPs or if it's just better client implementation...

XMPP is so bad on mobile that this persistent connection thingy and the whole XMPP protocol itself are effectively what prop up every single push notification on Android and Nintendo switch. True, Android vendors made a habit of killing background apps for misguided battery optimization reasons (less the case nowadays), which XMPP taught itself to work around in 2014/2015.

Same for media, it just works, you should try it? And funny you mention WhatsApp, it's effectively a dialect of XMPP running on a fork of ejabberd.

This should be solvable, although maybe a little meh. Client developers on platforms without unrestricted background connections need to run a server for push notifications. And server developers need to accept and use a push url from the clients.

If I understand correctly, Google and Apple have a way for clients to request push tokens, but in order to use the token, you have to authenticate as the app owner, so a client unaffiliated with the server can't simply send a push token to a server and have that be used ... Instead you'd need that push proxy server.

That proxy server comes with concerns about reliability and privacy and etc, but if you do pushes without cleartext content (and you should!), the footprint is minimal and you gotta do what you gotta do.

I don't follow xmpp/jabber, but I'd hope there's already an XEP for this. It's a pretty apparent need for the last I dunno 15 years and it has a clear solution.

With the right agitation, maybe you could get sharable platform push tokens and skip the intermediary app developer pusg server, but that seems unlikely.

You probably also want something in the push system to help trace push problems. For small chat servers and smallish client push proxy servers, I expect minimal operations staffing, but when messages are being delayed because of push problems, you want to be able to let affected clients know that they need to be more agressive with periodic/background connections until push works again. You may also want to let users or the administrators of the proxy push servers know as well. Pushes might be initiated late on the origin, delayed between the origin and the proxy, queued for a long time at the proxy, delayed between the proxy and platform push, or delayed within platform push (including on device delays from Doze, etc).

You've got to be able to detect that so you can make adjustments and reduce delay. Messaging delay reduces user satisfaction.

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

I really like Telegram, it's the closest thing to what I wish IM should be, but still it's so far from it and to be honest its apps suck now trying to shove the "premium" features down your throat. I prefer using TelegramX (or Forkgram to still be able to see statuses)

This is true. Telegram is fast, stable and has some leading and meaningful features. On mobile AND desktop.

I'm really surprised that nobody bothered making a fork of the Telegram open source client that works with XMPP.

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}'

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/

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."

> 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.

And Google Talk. And WhatsApp.

https://www.process-one.net/blog/whatsapp-facebook-erlang-an...

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.

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.

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.

The software playing field is different with AI. Like making nice mobile/desktop apps used to be a serious barrier.

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.

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.

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.

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.

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.

What stack did you land on?

You don't need to ask anyone else's permission. The thing that got me over the hump was wanting secure chat with an AI agent running on my own hardware. Asking WhatsApp for an API key just rubbed me up the wrong way.

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

I've been self-hosting XMPP for slightly more than 10 years now. I started out of necessity with 2/3 family members, so I would have reliable messaging while travelling on a tight bandwidth, and/or to places that would censor the usual alternatives. This turned into 20+ family members over time. Old friends, then colleagues, joined in about similar proportions. I'm experienced enough to never have "pitched it" or tried to "sell it" to them. I only tell them that this is what I use, and that, unlike the other commercial things they may be familiar with, it will keep working for as long as I'm alive to pay the hosting bills. That generally gets them curious-enough to try. About colleagues, some eventually start using it among themselves because it's a more "relaxed" experience than using Teams on their phone. I won't change the world that way (nor do I intend to), I just think that there is room for more than just one monopolistic and slowly-enshittifying network, and plenty for XMPP.

E2E encryption should be part of the main protocol spec and mandatory. It's 2026 now. Nobody needs a messenger that isn't encrypted.

Everybody has switched to OMEMO. It's the same encryption standard which Signal uses. It supports multiple devices and encrypted group chats as well.

OMEMO has superseded xmpp for a while now.