Make a single cross-platform client that implements every non-humorous XEP. If you tell people "on Android you should use this app, on iOS use that app" - you lose regular people fast. If you have a feature that only exists in one app on one platform, you also really lose people.
People don't really sign up for protocols, they download apps. Like I often refer to the fediverse as "Mastodon" even though I know that's not entirely correct, because it's the fastest, easiest way to communicate what I'm talking about - microblogging. So you really need a single, good app you can just tell people to download.
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.
This is effectively settled. Every client worth using has standardized on certain extensions, and there are server capability testers for it [0].
There are still a LOT of things very much up in the air, such as message deletion, which work inconsistently from client to client, but message history is not it.
call me out if I am wrong, but isn't history dependent on the server of the chatroom creator, and doesn't every server have different history settings and does it not handle encrypted messages fully?
Yes, XMPP server implementations typically give admins full control over data retention. Different use cases demand different settings, so it's quite adaptable to whatever needs you have.
I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
> so it's quite adaptable to whatever needs you have.
as a user you cannot, even if you self host, because you are not the one controlling message storage
> I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
you can load encrypted messages (including keys if they are needed to decrypt them if necessary) using a fresh login such that you can read them again?
This may sound stupid to a predominantly GNU/Linux audience, but as a FreeBSD user(and Linux user!), when a daemon is not available for FreeBSD, it's a very bad sign.
"Because Snikket is designed natively as a tightly integrated suite of Docker containers built around the Prosody XMPP server, running it natively on FreeBSD is complex."
FWIW I'm the founder of both the Snikket and Prosody projects. If you're a FreeBSD user, or even an experienced hands-on Linux sysadmin, I'd probably recommend going with Prosody, unless docker is your thing.
Snikket aimed to fill the gap for people who wanted an "out of the box" XMPP distribution kind of thing, and it's good at that. But shipping a bunch of software components with opinionated configurations doesn't really mesh well with distribution-level package management, and only really works with a container kind of ecosystem.
Both routes exist and are equally viable. Prosody has ports available for all the popular BSDs, and installing it should be a breeze. Just be prepared to then also set up a TURN server if you want calls, and potentially some web server stuff to if you want some of those features. After installing Prosody you can run 'prosodyctl check features' and it will tell you if you're missing any of the common stuff people want in a modern messaging app.
> 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.
Re: fediverse my point is - regular people just do not care about any of the fediverse-y parts of it. If I share a post I saw, I don't say "here's a thing I saw on the fediverse" - I just say "here's a thing I saw on Mastodon."
Plus the reality of the fediverse is if you want to use multiple platforms, you wind up needing multiple accounts anyway. Like if I want to upload to Peertube, I need to make a Peertube account, so we're back to where we started of having multiple places to follow people since I can't use my Mastodon account to upload to Peertube. I'm able to have some cross-platform interaction, like commenting on videos from mastodon - but there's issues there like, Pixelfed only showing people posts with images.
When talking to most people I just call the whole thing Mastodon and treat it like its a single app/service, because that's what people are used to. If I start trying to tout how the fediverse is a decentralized platform of multiple applications and you can kinda/sorta interact across platforms - people's eyes glaze right over. They just do not care.
For apps - I've never met a person that picks a messenger because its tweaked for their platform. They just prefer whatever their friends are on. iMessage is something of a odd case since Apple just rolls you into it automatically and presents it via the default app.
Re: Re: Fediverse. My point was more than indeed the Fediverse is more a technical detail than an actual cohesive platform, so it only makes sense to talk about Mastodon, whereas XMPP is more cohesive by virtue of instant messenging being a lot less opinionated.
It just so happens it splits into well-maintained projects supporting the concensus features, and dead or dying projects that don't, modulo a couple contrarians, with a couple more features floating in limbo, having finalized or draft specs that nobody really implements.
That sort of problem isn't best fixed by centralization on one client/server but just certification, which Conversations/ModernXMPP already leads.
As for apps, yes normal people aren't very conscious of what a native app is, but they do feel when their app lags on their older phone, doesn't recieve push notifications, or just looks a little odd in places, which can happen in a one size fits all app. Some of the most popular messengers, like WhatsApp or Telegram, to my knowledge use platform specific tooling, and normal people genuinely appreciate how snappy they feel.
But the issue is more so about developer time. Yes a cross platform app lets you reuse the same work everywhere, but the lead developer still has personal blind spots, and might simply not consider or be able to test things like bespoke Apple workarounds for non-iCloud/encrypted chat push.
Plus it's a communication protocol, like email; we should be expecting people reimplementing it in the weirdest of places. For software like this, the duplication of effort is what drives you to make an elegant design in the first place.
Sorry but I just fundamentally disagree about the app centralization.
If you want xmpp to gain traction you need an app that exists on both mobile platforms. It can (and should) have per-platform tweaks and everything to be performant. But a person needs to be able to just tell their friend a single app, they need to be able to find it in their app store.
The question is "how does xmpp gain traction?" and the answer is having a single flagship app that runs on everything.
If a person needs to recommend a single app is because most people are tech illiterate and don't understand what protocols are, because no one tells them.
I can expect this from our parents and grandparents, but not from younger generations that were born with PCs and smartphones. They need to learn; we need to educate them. Otherwise they will stay being the perfect fodder for Big Corpos and their monopolistic tactics.
We need to start focusing on the protocols, not the platforms.
Pidgin 2.x (latest stable branch) is unfortunately over a decade behind at this point. The developers are working on a big rewrite (3.x) but it's nowhere near complete or ready for use yet.
In short, I wouldn't recommend Pidgin for someone who wants a modern messaging app.
>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".
Based on web browser statistics I've seen, most people use Chrome, some of them use Safari on their phones. There are also people who use Edge sometimes.
But most people seem to use Chrome on every device, no matter how much I wish they didn't.
Plus the sad reality is even if they're not using Chrome they're probably still using Chrome - most browsers are based on Chromium. You have Safari and Firefox, nearly everything else is just Chrome.
Also last I checked - on iOS devices even if you use Chrome, you're really using Safari - I believe apple forces all web content to be rendered using the built-in WebKit.
This comes from the before times when Internet Explorer was full of holes and Chrome was a usable browser with regular updates and before Firefox worked with all websites well.
Google has since spent the time making Chrome more locked down and user-hostile from a privacy perspective but the conventional wisdom for years was “just use Chrome” (for good reason) and that inertia continues :/
For email - most people use the official app and assume they have to use it.
You sign up for Gmail, you get the Gmail app. You sign up for Outlook, you get the Outlook app. 1 service = 1 app.
For browser - on mobile most people use whatever the default browser on their device is. On desktop - Chrome. Pretty much everybody just downloads and uses Chrome.
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.
Jabber/XMPP started to suck at the moment we've started using smartphones that keep reconnecting between wifi and mobile networks as i move around. relying on that single persistent TCP connection does not make sense anymore. This is huge pain with IRC as well... And no, i will not run server-side proxy irc client that is supposed to keep me reachable while im reconnecting.
Also sending media (or even rich text) never really worked as each client implemented it differently. While whatsapp just works...
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.
XEP-0198 is great for session management. But, Android and iOS don’t really want apps maintaining persistent sockets. WhatsApp solves this by leveraging the push infrastructure when the app is suspended.
XMPP also supports push notifications using Android and iOS infrastructure. But it also works with persistent connections, and the client notifies server when the app is not in foreground, for server to push only important data (such as direct message) to conserve battery.
It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day.
>it doesn't support upload resumption in case the network is bad.
Re: P2P, it's kind of making an impromptu comeback. If you want some trivia, IIRC, the developer of Conversations was on some trans-continental flight few months ago and realized that XMPP works just fine on the free onboard internet plan (being considered by the firewall as legitimate "social-usage"), except for HTTP upload. So now, when your HTTP upload fails, Conversations asks if you want to try again with P2P, so you can send your images for free from the plane :-)
XMPP was not designed for human chat only, and XMPP foundation promotes it as an IoT communication protocol, like MQTT. Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow.
I use XMPP almost exclusively for the last 10 years and don't see any major issues, not with the protocol, not with the clients. Everything is pretty reliable and works fine.
Having media out of band causes some problems but eases others. Having a separate tcp window for media and messages is pretty valuable. Additionally, if media is separate, you might run it in different locations than chat.
HTTP may not have native resumption, but it's not hard to do partial upload and resumption over HTTP, you just need agreement on parameters / a protocol to determine where to resume from.
? I've done it a few times. It worked fine on Nokia S40 and the version of J2ME they run can't even seek backwards in files.
It's a three part recipe:
a) send a request to upload with whatever auth you need, some stable identifier for the file and the file size. Ideally a nice checksum to confirm the file was not corrupted in transit; TLS should protect you, but I've seen things, a 32-byte sha256 checksum offers protection from a lot of things.
b) if the upload is unfinished, you'll get a url (or whatever) to post to and a starting offset (0 on the first time); if the upload is complete, you'll get a download url to send to your correspondent. (or an error like file too big, try again later, go away, whatever)
c) upload the file to the url. Maybe get a status if the upload finishes and you're still online to receive it. Status could indicate error or a download url. If you timeout or get a retriable error, go back to part a.
It's not rocket science or anything. Maybe it would be hard to get done in the XMPP ecosystem, but it's simple enough to do with any stack that's got big enough media that resuming uploads is relevant.
Of course using TCP has nothing to do with head-of-line blocking.
Only if you blindly do write(socket, fileptr, sizeof(file)), it starts to matter, but, you know, people did not start writing for TCP/IP yesterday.
If you have a decent protocol, it splits files (and texts as well) into chunks, and sends them in prioritized order, text chunks having higher priority than binary chunks. The server re-assembles the chunks then.
The fact that such a simple way of multiplexing data is a discovery for XMPP fanboys is very revealing.
You can certainly chunk things and interleave/multiplex interactive and bulk data.
But it's easy to end up with low throughput, because you limit how much unacked bulk data you send, because you don't want to overqueue bulk data and not be able to immediately write interactive messages.
And it's easy to end up with high latency, because despite the limits above, you queued too much and interactive messages need to wait. Or you sent bulk data and there was a burst of packet loss and new data can't be received until the missing packets are resent and received.
> people did not start writing for TCP/IP yesterday.
And yet you find resuming uploads over http to be too hard?
And yet the OS is doing just that when you open two TCP streams. It packs them into ethernet frames and keeps track of the acks. Only the OS does not know the context, so it prioritises both streams equally. (Unless some evil magic is involved.)
>And yet you find resuming uploads over http to be too hard?
Me? No. Xmpp developers? Apparently yes, as it's neither in any of the XEPs nor in any of the clients.
> Only the OS does not know the context, so it prioritises both streams equally.
Of course there's prioritization options on socket APIs since forever (DSCP), but usage is limited, because it requires coordination and coordination is hard.
Even with equal prioritization, when you overuse on the media connection and that results in packet loss and congestion window reduction, chat messages don't have to wait for all the dropped packets to be resent over multiple round trip times. If you're lucky the chat connection didn't see any of the loss, and even if you're not, you've likely got a smaller queue on your chat connection than your media connection.
This also doesn't prohibit client driven prioritization --- when connecting, get caught up on chat before processing media. Maybe pause media while sending chat messages or if server acks are slow. Server driven prioritization is hard, because probably your http media servers don't have information on the chat connection --- but if a client stops reading from the media connection, the server will get the message eventually.
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.
Bit of a Radio Yerevan Situation. Not even the various emergency broadcast app reliably get timely push notifications.
The thing about these notifications seem to be that apps that regularily get notifications from the the app get them reliably.
This is based on the observation that xmpp-contacts I'm in regular contact with seem to get notifications quickly and contacts I talk to less regularily not so much.
I don't think Apple is the weak link here. Somewhere there must be a gateway between an XMPP server and the APNS. Maybe the server isn't handling it well. I do know APNS was super annoying to deal with before they added the HTTP API.
Also huh, I've been to Yerevan but never heard of Radio Yerevan jokes until now, that's pretty funny.
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...
I've been using it for years, so has my family and recently a group of some 60 friends with whom we communicated about a large party ont of my friend and me organised. I made an invitation site with an instance of converse.js at the bottom of the page, pointed at an anonymous group on my (Prosody) server. We just mostly Conversations or one of its forks on Android - no fruit phones among us - and Converse.js on web, higher on the same server which hosts all our other services (mail, "cloud", media, etc.). Once installed and configured it is maintenance-free, lightweight and reliable.
That is how you gain traction: by having people use it, realise the user experience is comparable or in some cases superior to that of other messaging systems - the party chat thing I mentioned above being a good example - and then realise they dont need to hand over their data to an ad broker (Google, Metafacebook, the fruit factory) or the government (all of them through some "chat control" type law).
If you're talking about the push notifications experience, then XEP-0357 solves this, but app developers have to host the infrastructure which the XMPP server calls back to and dispatches the notifications to Apple or Google. Last time I used Monal on iOS this was solved and worked well. On Android I think most apps still prefer to keep their own background connection open.
Of note, Conversations and some other XMPP clients can act as UnifiedPush Distributors (i.e. they use their own reliable persistent connection to proxy notifications for other apps). Some mastodon (tusky, fedilab, …), matrix (fluffy chat, element x, …) clients use it¹
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.
Taking a quick look, this one is marked deferred; I don't know what that means, but it sounds like it's not an accepted standard?. It requires the application push server to be an XMPP server (which I suspect is challenging for client developers, compared to having a https url that takes a POST or similar) and doesn't include a method for a client to request a test push to validate the setup or discuss feedback to the client for push failure.
This doesn't feel solved to me.
I didn't review XEP-0198 closely, based on perhipheral ecosystem interaction, I do think that one is solved.
Both Monal and Conversations support XEP-0357. Each project runs their own XMPP-to-Apple/Google gateway for push notifications. It has to be that way because the gateway server and client phone application have to be signed by the same developer account.
The client phone app tells your XMPP server which gateway to use (or maybe it's vice-versa, the gateway contacts your server. I forget). In any event XMPP servers like Prosody support this out-of-the-box.
> 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)
Telegram has by far the best bot support of any platform, with Discord a close second followed by Slack.
This is what the FOSS services kinda tend to glaze over, SO MUCH of my personal and professional life is managed by chatting with services that are represented as bots in a chat.
I looked into that very briefly about a decade or so ago: it would be very difficult to get it done and maintained in practice. XMPP leans towards the "dumb server/smart client" side of the trade-off, while Telegram is the exact opposite: while an XMPP client establishes and maintains a session and its state, retrieves a list of discussions, for each, requests and processes new messages, and infers reas markers and counts (a bit like a traditional mail client like thunderbird), Telegram maintains the session and the client state on the server and the client is a thin layer to just display it.
Precisely, which isn't much, and on top of that, you would have those modified as well to map to XMPP concepts and specifics. That said, I do believe that XMPP deserves a beautiful Qt client. There is Kaidan (QtQuick), but it's very opinionated (practically incompatible with groupchats and preferring a mobile UI paradigm)
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.
I am ok with Electron if it is needed for Matrix. Also, Telegram has a C++ desktop client.
Also, I would not advise to add proprietary repositories as you grant them root access to your system which is against security practices such as the principle of minimum privileges and defence-in-depth.
Same, it might conflicts a little with the desire to have a single application, but I want a native application for each platform which uses native UI and libraries. There's no reason a messaging app should be more than e.g. 40MB.
I would rather prefer browser app like Whatsapp/Telegram, I am not going to install extra app and switching windows to see chat when I spend most of the day in browser on desktop
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.
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.
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."
> 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'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.
Teams. Your CFO keeps telling your head of Projects/Engineering that he's already paying for it anyway. And your helpdesk loves it because it's sharepoint all the way down and up, and they can shine their "Microsoft Certified Kung-Fu level Sharepoint Master Accreditee" certification.
Our helpdesk doesn't use Sharepoint though :) And we're a Google Apps company, so we don't even have a M365 subscription.
But you're right, the best competitive advantage of Teams is that it's "free"[0]. But that's about it, it's objectively bad in all other ways - anyone claiming otherwise has Stockholm syndrome and is in denial =)
Just the fact that, as a consultant, it's literally impossible to connect to multiple teams workspaces with the same client. The OFFICIAL Microsoft advice is to use Private Browsing in separate browsers...
Meanwhile on Slack I can just hit cmd-number and swap between clients. AND we can have shared channels over instances, like $vendor having a support channel on our Slack with their actual people with their own accounts.
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.
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 really don't understand this attitude. The landscape has changed in 25 years, XMPP was built from the ground-up for extensibility. And that was the right approach, since it managed to improve continuously, and is now on par with the dominant alternatives. In that timespan, it survived 2 or 3 generations of messengers. It will survive Facebook, WhatsApp, Telegram and others (which, by their proprietary and centralized nature, are prone to enshittification).
For anyone paying attention, it should be the clear "safe bet" for what to try next/keep at hand somewhere.
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.
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.
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.
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.
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.
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.
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.
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.
Just a self-hosted Zulip instance for family members, exposed externally via Tailscale. I wanted to try Mongoose and Snikket (possibly Prosody as well, but can't recall), but I guess my infrastructure didn't want to line up directly with what they want for a quick start. shrug
My attempts to use XMPP mostly start and end very quickly with the fact that there isn't a single good native XMPP client for Mac or iOS. None of Monal, Siskin or Beagle are a good experience, ChatSecure appears to be abandonware and Prose is Yet Another Web App.
Most of the critique in the post is about the low quality of Signal's app, which has zero to do with the protocol. And frankly almost every XMPP client was vastly worse in quality terms than Signal is and OTR regularly just produced garbage. It had a chance. Signal is not widespread because the only reason to use it is high privacy consciousness or being in the government and wanting secure chat with automatic deletion for conversations you're not supposed to be having.
It's a little like asking "Carburetors: How do we gain traction?"
XMPP is not a well designed protocol in many ways. There's no particular reason for anyone to care.
The fundamental question is: why should I use Jabber? What's the use case that makes it better than WhatsApp, Signal, et cetera?
My most-used messaging app is SMS because if you have a cell phone, you have SMS. Example this morning is I made a connection with a handyman recommended by a friend. Text message, and it just worked.
So what's the compelling reason to move to Jabber? Why should my 92-year-old mother use it?
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.
Is it worth it to overcome network effect? Maybe just make something so useful that it is even if only people who listen to you use it, which XMPP is, and recommend it to people who are willing to try (not only because of vague curiosity, which fades very quickly, but because it's useful to them).
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.
I disagree. XMPP wasn't designed for it, and there are already others that have done E2EE better, while still having some downsides. The only way XMPP has an edge is by not doing E2EE.
Who are those people having lot of time to re-read their old message history? I assume most people only read last several messages in a chat. This matches the real life conversations which are not stored anywhere. However, police will definitely be happy to discover that your many years messaging history is intact.
I would rather want a feature, like Telegram has, where you can set auto-delete of all messages older than N days.
>Who are those people having lot of time to re-read their old message history?
Everyone who has to, say, prove that they kept paying their rent for a year without interruptions. You sent a photo of your money transfer from the bank app to your landlord, and he sends the "received" screenshot from his bank app.
Moreover, a lot (even most) people make personal notes by sending messages to themselves.
For me searching my old messages is really useful. I don't scroll back through history but I'll search for things like "plumber" to find the number of a plumber a friend texted me a while back.
the only people that really trust the police are ones that never actually had to deal with the police (which may be a whole lot of people). however, if you ever have an unfortunate situation to have a run in with the police, there is a good chance you will not be all that trusting any longer. people trust the idea of police more so than anything else
Well, true. But even so, having the history intact is also a way to remove suspicions from yourself.
"Where were you during the event X? I was very far from the place you are interested in, as can be proven by this photo, sent to my grandma, have a look at the history in her phone."
Businesses want to analyze internal company messages. Chat protocols / platforms need to make inroads with one of the core audiences for online chat. Those are largely taken right now, (slack/teams business, discord gaming/oss). If it is personal/small group messaging, several E2EE options already exist, though I understand Jabber/XMPP is trying to be in the chatroom genre
You can do E2E encryption for organizations, you just establish all conversations as at least 3-way conversations: the two members of the org, and the org itself. You let the server refuse to host any conversation it isn't privy to, and then apps that support organization mode automatically add the org listener, and users using third-party clients can add it manually.
There is literally nothing about enterprise inspecting proxies that requires the client operate without default and always on crypto. That makes no sense at all.
The way businesses handle this is by installing a certificate they manage and deploy to their proxies.
True, segmentation is already happening with users choosing apps based on geography, age, and sometimes by social group. It’s possible to target and win over a select group of people if you have a compelling feature or an experience that’s geared towards their needs. You just have to decide who you are focusing on.
I can easily imagine a future where people switch between three messengers, one for general communications with acquaintances and family, one for work, and one for their social circle. Many already do this with social networks.
I am using Whatsapp and I MUST have some SMS app in phone, if your app will support SMS and on top of that will provide Jabber/XMPP messages over data I will be more than happy to replace my SMS app with your app.
Sadly seems there is pretty much NONE apps where dev would bother to implement support for simple SMS. And if your app doesn't support SMS I am not going to install any other obscure app since I need SMS to receive 2FA codes/delivery notifications/doctor appointments, etc.
Signal used to be liek this until 2022, not many people used it, but at least you could use it for SMS and if there was Signal contact you could use their network, in their wisdom they removed SMS feature, so Signal was removed from phones of my whole extended family since we need SMS and not going to have extra Signal without SMS, if anyway majority use Whatsapp.
Sounds like the same issue as with Mastodon. The vast majority of people are not interested in a 'protocol' (or even know what that is), they do not care what protocol powers their _app_, they just care about their app
People don't really sign up for protocols, they download apps. Like I often refer to the fediverse as "Mastodon" even though I know that's not entirely correct, because it's the fastest, easiest way to communicate what I'm talking about - microblogging. So you really need a single, good app you can just tell people to download.
There are still a LOT of things very much up in the air, such as message deletion, which work inconsistently from client to client, but message history is not it.
[0] https://compliance.conversations.im/
I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
as a user you cannot, even if you self host, because you are not the one controlling message storage
> I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.
you can load encrypted messages (including keys if they are needed to decrypt them if necessary) using a fresh login such that you can read them again?
[0] https://snikket.org/start/
"Because Snikket is designed natively as a tightly integrated suite of Docker containers built around the Prosody XMPP server, running it natively on FreeBSD is complex."
Holy shit
Snikket aimed to fill the gap for people who wanted an "out of the box" XMPP distribution kind of thing, and it's good at that. But shipping a bunch of software components with opinionated configurations doesn't really mesh well with distribution-level package management, and only really works with a container kind of ecosystem.
Both routes exist and are equally viable. Prosody has ports available for all the popular BSDs, and installing it should be a breeze. Just be prepared to then also set up a TURN server if you want calls, and potentially some web server stuff to if you want some of those features. After installing Prosody you can run 'prosodyctl check features' and it will tell you if you're missing any of the common stuff people want in a modern messaging app.
Hope this helps :)
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).
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.
Plus the reality of the fediverse is if you want to use multiple platforms, you wind up needing multiple accounts anyway. Like if I want to upload to Peertube, I need to make a Peertube account, so we're back to where we started of having multiple places to follow people since I can't use my Mastodon account to upload to Peertube. I'm able to have some cross-platform interaction, like commenting on videos from mastodon - but there's issues there like, Pixelfed only showing people posts with images.
When talking to most people I just call the whole thing Mastodon and treat it like its a single app/service, because that's what people are used to. If I start trying to tout how the fediverse is a decentralized platform of multiple applications and you can kinda/sorta interact across platforms - people's eyes glaze right over. They just do not care.
For apps - I've never met a person that picks a messenger because its tweaked for their platform. They just prefer whatever their friends are on. iMessage is something of a odd case since Apple just rolls you into it automatically and presents it via the default app.
It just so happens it splits into well-maintained projects supporting the concensus features, and dead or dying projects that don't, modulo a couple contrarians, with a couple more features floating in limbo, having finalized or draft specs that nobody really implements.
That sort of problem isn't best fixed by centralization on one client/server but just certification, which Conversations/ModernXMPP already leads.
As for apps, yes normal people aren't very conscious of what a native app is, but they do feel when their app lags on their older phone, doesn't recieve push notifications, or just looks a little odd in places, which can happen in a one size fits all app. Some of the most popular messengers, like WhatsApp or Telegram, to my knowledge use platform specific tooling, and normal people genuinely appreciate how snappy they feel.
But the issue is more so about developer time. Yes a cross platform app lets you reuse the same work everywhere, but the lead developer still has personal blind spots, and might simply not consider or be able to test things like bespoke Apple workarounds for non-iCloud/encrypted chat push.
Plus it's a communication protocol, like email; we should be expecting people reimplementing it in the weirdest of places. For software like this, the duplication of effort is what drives you to make an elegant design in the first place.
If you want xmpp to gain traction you need an app that exists on both mobile platforms. It can (and should) have per-platform tweaks and everything to be performant. But a person needs to be able to just tell their friend a single app, they need to be able to find it in their app store.
The question is "how does xmpp gain traction?" and the answer is having a single flagship app that runs on everything.
I can expect this from our parents and grandparents, but not from younger generations that were born with PCs and smartphones. They need to learn; we need to educate them. Otherwise they will stay being the perfect fodder for Big Corpos and their monopolistic tactics.
We need to start focusing on the protocols, not the platforms.
In short, I wouldn't recommend Pidgin for someone who wants a modern messaging app.
They've been working on a version 3 for years but no idea if that will ever happen.
As for version 3, yeah turns out that things take a very long time a tiny team that has zero financial support.
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".
But most people seem to use Chrome on every device, no matter how much I wish they didn't.
Also last I checked - on iOS devices even if you use Chrome, you're really using Safari - I believe apple forces all web content to be rendered using the built-in WebKit.
Google has since spent the time making Chrome more locked down and user-hostile from a privacy perspective but the conventional wisdom for years was “just use Chrome” (for good reason) and that inertia continues :/
You sign up for Gmail, you get the Gmail app. You sign up for Outlook, you get the Outlook app. 1 service = 1 app.
For browser - on mobile most people use whatever the default browser on their device is. On desktop - Chrome. Pretty much everybody just downloads and uses Chrome.
It just needs feature versions - you support this one, means you support all of the features deemed important for users, no partial mishmash.
It’s mostly whining that the world is too unfair because capitalism and people are dumb for choosing Signal, etc.
Also sending media (or even rich text) never really worked as each client implemented it differently. While whatsapp just works...
>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.
No it doesn't. Firstly, an out-of-band upload is ridiculous. Secondly, it doesn't support upload resumption in case the network is bad.
It is a bit, true, but the alternatives are worse. XEP-0231 (Bits of Binary) Base64-encoded data inside the text message is more ridiculous idea. Direct P2P connections, which were widely used before HTTP upload, are mostly not working in our day.
>it doesn't support upload resumption in case the network is bad.
There's a draft for HTTP for it: https://httpwg.org/http-extensions/draft-ietf-httpbis-resuma...
It's not that "alternatives are worse, it's that xmpp is a broken protocol, which doesn't include support for anything, even such a basic thing"
>There's a draft
LOOOOOOOOL
Which means that it will never work for human messaging, due to all the IoT cruft.
>Thanks to Daniel, the author of this post, we now have communication profiles which the IM-oriented servers and clients follow.
LOL, he only implemented p2p transfers when it bit himself in the tail on a plane flight.
Conversations is the best of them all, but it doesn't mean that it is good.
HTTP may not have native resumption, but it's not hard to do partial upload and resumption over HTTP, you just need agreement on parameters / a protocol to determine where to resume from.
What for?
>t's not hard to
LOOOOOOOOL
> LOOOOOOOOL
? I've done it a few times. It worked fine on Nokia S40 and the version of J2ME they run can't even seek backwards in files.
It's a three part recipe:
a) send a request to upload with whatever auth you need, some stable identifier for the file and the file size. Ideally a nice checksum to confirm the file was not corrupted in transit; TLS should protect you, but I've seen things, a 32-byte sha256 checksum offers protection from a lot of things.
b) if the upload is unfinished, you'll get a url (or whatever) to post to and a starting offset (0 on the first time); if the upload is complete, you'll get a download url to send to your correspondent. (or an error like file too big, try again later, go away, whatever)
c) upload the file to the url. Maybe get a status if the upload finishes and you're still online to receive it. Status could indicate error or a download url. If you timeout or get a retriable error, go back to part a.
It's not rocket science or anything. Maybe it would be hard to get done in the XMPP ecosystem, but it's simple enough to do with any stack that's got big enough media that resuming uploads is relevant.
Now tell your girlfriend's mother to do the same.
To prevent head-of-line blocking.
Of course using TCP has nothing to do with head-of-line blocking.
Only if you blindly do write(socket, fileptr, sizeof(file)), it starts to matter, but, you know, people did not start writing for TCP/IP yesterday.
If you have a decent protocol, it splits files (and texts as well) into chunks, and sends them in prioritized order, text chunks having higher priority than binary chunks. The server re-assembles the chunks then.
The fact that such a simple way of multiplexing data is a discovery for XMPP fanboys is very revealing.
But it's easy to end up with low throughput, because you limit how much unacked bulk data you send, because you don't want to overqueue bulk data and not be able to immediately write interactive messages.
And it's easy to end up with high latency, because despite the limits above, you queued too much and interactive messages need to wait. Or you sent bulk data and there was a burst of packet loss and new data can't be received until the missing packets are resent and received.
> people did not start writing for TCP/IP yesterday.
And yet you find resuming uploads over http to be too hard?
>And it's easy to end up with high latency,
And yet the OS is doing just that when you open two TCP streams. It packs them into ethernet frames and keeps track of the acks. Only the OS does not know the context, so it prioritises both streams equally. (Unless some evil magic is involved.)
>And yet you find resuming uploads over http to be too hard?
Me? No. Xmpp developers? Apparently yes, as it's neither in any of the XEPs nor in any of the clients.
Of course there's prioritization options on socket APIs since forever (DSCP), but usage is limited, because it requires coordination and coordination is hard.
Even with equal prioritization, when you overuse on the media connection and that results in packet loss and congestion window reduction, chat messages don't have to wait for all the dropped packets to be resent over multiple round trip times. If you're lucky the chat connection didn't see any of the loss, and even if you're not, you've likely got a smaller queue on your chat connection than your media connection.
This also doesn't prohibit client driven prioritization --- when connecting, get caught up on chat before processing media. Maybe pause media while sending chat messages or if server acks are slow. Server driven prioritization is hard, because probably your http media servers don't have information on the chat connection --- but if a client stops reading from the media connection, the server will get the message eventually.
On Android, I've never had any connection issues with either Signal or XMPP, so I would say that this problem is solved.
The thing about these notifications seem to be that apps that regularily get notifications from the the app get them reliably.
This is based on the observation that xmpp-contacts I'm in regular contact with seem to get notifications quickly and contacts I talk to less regularily not so much.
Sadly this dependent on apples whims
Also huh, I've been to Yerevan but never heard of Radio Yerevan jokes until now, that's pretty funny.
That is how you gain traction: by having people use it, realise the user experience is comparable or in some cases superior to that of other messaging systems - the party chat thing I mentioned above being a good example - and then realise they dont need to hand over their data to an ad broker (Google, Metafacebook, the fruit factory) or the government (all of them through some "chat control" type law).
https://xmpp.org/extensions/xep-0357.html
Many Android apps give the option of using either FCM (Firebase Cloud Messaging, Google's push service), UnifiedPush or polling.
¹: https://unifiedpush.org/users/apps/
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.
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.
Yes, and it has been solved long time ago already and is now widely supported by both servers and clients.
> I don't follow xmpp/jabber, but I'd hope there's already an XEP for this.
See XEP-0198 from 2004 and XEP-0357 from 2015.
Taking a quick look, this one is marked deferred; I don't know what that means, but it sounds like it's not an accepted standard?. It requires the application push server to be an XMPP server (which I suspect is challenging for client developers, compared to having a https url that takes a POST or similar) and doesn't include a method for a client to request a test push to validate the setup or discuss feedback to the client for push failure.
This doesn't feel solved to me.
I didn't review XEP-0198 closely, based on perhipheral ecosystem interaction, I do think that one is solved.
The client phone app tells your XMPP server which gateway to use (or maybe it's vice-versa, the gateway contacts your server. I forget). In any event XMPP servers like Prosody support this out-of-the-box.
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 what the FOSS services kinda tend to glaze over, SO MUCH of my personal and professional life is managed by chatting with services that are represented as bots in a chat.
Frankly speaking, Telegram is also shit. It just sucks a bit less than the rest of them.
Also, I would not advise to add proprietary repositories as you grant them root access to your system which is against security practices such as the principle of minimum privileges and defence-in-depth.
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.
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/
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.
And it can't just be an optional feature in some clients, it needs to be something that just works everywhere.
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.
So, Cisco Jabber (now Webex)? You can't really compete against Microsoft and its bundling strategy. Even Slack is dying, unfortunately.
Webex can't be run on-prem, can it? I vaguely know about the old Cisco Jabber.
But you're right, the best competitive advantage of Teams is that it's "free"[0]. But that's about it, it's objectively bad in all other ways - anyone claiming otherwise has Stockholm syndrome and is in denial =)
Just the fact that, as a consultant, it's literally impossible to connect to multiple teams workspaces with the same client. The OFFICIAL Microsoft advice is to use Private Browsing in separate browsers...
Meanwhile on Slack I can just hit cmd-number and swap between clients. AND we can have shared channels over instances, like $vendor having a support channel on our Slack with their actual people with their own accounts.
[0] If you have M365 anyway.
Thankfully we use Slack where I work. The cross-org channels are cool.
Probably the Facebook chat is still XMPP internally even today.
https://www.process-one.net/blog/whatsapp-facebook-erlang-an...
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.
For anyone paying attention, it should be the clear "safe bet" for what to try next/keep at hand somewhere.
but what ?
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.
This is (to me) a big issue when using bots, for example. I need a non-ambiguous trigger for them.
https://xmpp.org/software/?category=clients&xeps=0513
I wanted to self-host a chat service where I can control my bots and AIs, but with no native tagging functionality makes it really janky to work with.
Discord and Telegram Just Work, but I'd much rather have the whole thing in my control.
Buzz[0] seems nice, but for one person an 5 bots having a full-ass postgres+redis+s3 setup seems completely bonkers.
[0] https://github.com/block/buzz
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'll ensure the wrong people don't end up in your chats.
For use on mobile, run it in a tmux or screen session and reconnect over ssh.
It _works_, but the limitations of Jabber without 42 different optional extensions became apparent pretty quickly.
It's a little like asking "Carburetors: How do we gain traction?"
XMPP is not a well designed protocol in many ways. There's no particular reason for anyone to care.
My most-used messaging app is SMS because if you have a cell phone, you have SMS. Example this morning is I made a connection with a handyman recommended by a friend. Text message, and it just worked.
So what's the compelling reason to move to Jabber? Why should my 92-year-old mother use it?
I would rather want a feature, like Telegram has, where you can set auto-delete of all messages older than N days.
Everyone who has to, say, prove that they kept paying their rent for a year without interruptions. You sent a photo of your money transfer from the bank app to your landlord, and he sends the "received" screenshot from his bank app.
Moreover, a lot (even most) people make personal notes by sending messages to themselves.
Most people trust the police. This might not be justified in your state, but most people still do.
"Where were you during the event X? I was very far from the place you are interested in, as can be proven by this photo, sent to my grandma, have a look at the history in her phone."
If message history is important it should be backed up on the receiver's end after decryption, like WhatsApp and signal do.
Businesses want to analyze internal company messages. Chat protocols / platforms need to make inroads with one of the core audiences for online chat. Those are largely taken right now, (slack/teams business, discord gaming/oss). If it is personal/small group messaging, several E2EE options already exist, though I understand Jabber/XMPP is trying to be in the chatroom genre
The way businesses handle this is by installing a certificate they manage and deploy to their proxies.
chat is network effect, so a chat app needs to answer "which network of people" if the creators about traction?
I can easily imagine a future where people switch between three messengers, one for general communications with acquaintances and family, one for work, and one for their social circle. Many already do this with social networks.
The beginning was complaining about Signal! What is XMPP needed for then? Also, doesn't seem like many people have friends on either of them.
I am using Whatsapp and I MUST have some SMS app in phone, if your app will support SMS and on top of that will provide Jabber/XMPP messages over data I will be more than happy to replace my SMS app with your app.
Sadly seems there is pretty much NONE apps where dev would bother to implement support for simple SMS. And if your app doesn't support SMS I am not going to install any other obscure app since I need SMS to receive 2FA codes/delivery notifications/doctor appointments, etc.
Signal used to be liek this until 2022, not many people used it, but at least you could use it for SMS and if there was Signal contact you could use their network, in their wisdom they removed SMS feature, so Signal was removed from phones of my whole extended family since we need SMS and not going to have extra Signal without SMS, if anyway majority use Whatsapp.