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?
XMPP still hasn't settled chat history? Wow, I remember that from like 12 years ago. But also sometime in the last 12 years, they added E2EE which does complicate things.
>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.
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.
> People don't really sign up for protocols, they download apps.
This is both true and also flies in the face of what XMPP (and Mastodon-flavored ActivityPub-powered fediverse of microblogs-and-more) is supposed to be about—and it's both true and yet people understand what "email" means without managing to run into major issues when banging out a reply to alice@gmail.example in response to a message that landed in the recipient's inbox @yahoo.com—nor worry too much about their SMSes being delivered by AT&T to their friend who uses Verizon (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 a big deal to adopt email-like identifiers without actually being/implying that Internet-standard email services are available because 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 leveraged and converted into 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.
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.
I'd like Jabber to establish itself as the federated, non-E2EE chat platform. Forget OMEMO, it's too little too late. You want E2EE so badly, you use Signal and deal with the glitchiness. There's a reason Telegram is more popular; most people take stability and features over security.
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.
And forget extensions. If your server uses extensions, it's not Jabber anymore. That's why you also drop the name XMPP.
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.
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.
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.
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.
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)
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 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.
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?
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.
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.
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.
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.
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.
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).
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.
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.
"Signal doesn’t actually suck. It’s fine. It gets the job done. It lets me communicate with my friends."
The beginning was complaining about Signal! What is XMPP needed for then? Also, framing it as the go-to that your friends are on is unusual; normally people say "Signal is great, too bad nobody I know uses it."
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
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.
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.
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.
[0] https://snikket.org/start/
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/
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.
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.
This is both true and also flies in the face of what XMPP (and Mastodon-flavored ActivityPub-powered fediverse of microblogs-and-more) is supposed to be about—and it's both true and yet people understand what "email" means without managing to run into major issues when banging out a reply to alice@gmail.example in response to a message that landed in the recipient's inbox @yahoo.com—nor worry too much about their SMSes being delivered by AT&T to their friend who uses Verizon (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 a big deal to adopt email-like identifiers without actually being/implying that Internet-standard email services are available because 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 leveraged and converted into 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’s mostly whining that the world is too unfair because capitalism and people are dumb for choosing Signal, etc.
It just needs feature versions - you support this one, means you support all of the features deemed important for users, no partial mishmash.
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.
And forget extensions. If your server uses extensions, it's not Jabber anymore. That's why you also drop the name XMPP.
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...
On Android, I've never had any connection issues with either Signal or XMPP, so I would say that this problem is solved.
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.
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.
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)
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.
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?
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'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.
Probably the Facebook chat is still XMPP internally even today.
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.
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.
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
The beginning was complaining about Signal! What is XMPP needed for then? Also, framing it as the go-to that your friends are on is unusual; normally people say "Signal is great, too bad nobody I know uses it."
I would rather want a feature, like Telegram has, where you can set auto-delete of all messages older than N days.
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?