To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Also, it often happens that when a client developers need some feature that honestly should be done by a server, a developer still does this on a client, because it's all he has, with subpar results.
Absent leadership from XSF also plays a role. This club now mostly cares about bureaucracy and following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there. That's why it is unlikely for any great product to appear under such guidance.
We're trying a different approach, maybe we'll even succeed. If so, you'll hear about it on HN.
https://play.google.com/store/apps/details?id=im.quicksy.cli...
> a product, which can be easily deployed and will work consistently on every platform.
Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp.
One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably.
So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)
Email info@xabber.com, we'll send you a link to test version of Xabber for iOS. We hope to release it this month. It even has voip calls, for real!
When they have dropped Gtalk and went with Hangouts (likely, because of a WhatsApp envy), crippling XMPP compatibility one step at a time, they have claimed the reason for it is that it is 'impossible' to achieve great chat performance with XMPP. Of course, that was a lie. It is quite possible, and we're doing just that.
How could anything an XMPP server do affect how a client adds a contact?
That is no excuse for doing embrace, extend and extinguish as your Xabber seems to be attempting with the XMPP standard. I can't help but note that the Xabber project has outright rejected OMEMO capability.
If you are extending XMPP in incompatible ways (as Whatsapp did) it is only ethical to clearly state that to potential users.
2. We don't 'outright reject OMEMO capability'. I reject OMEMOdiots who moan excessively because their wishes aren't satisfied on the spot.
Why are not they satisfied? Because XMPP does not have a reliable control of message delivery, no way to remove messages from message archive, no good group chats, no client sync protocol, no way to revoke session tokens, no way to know which messages in archive were read, no way to add reactions to messages, no way to do threaded conversations, and while we're building all that we're constantly attacked by individuals who demand us drop everything we do and urgently add OMEMO so they can feel safe (and do it at our own expense, of course).
We'll provide some E2EE capability, but only after we are finished with everything else that we consider more important than this.
3. Extending XMPP in incompatible ways, I'll cover this a bit.
Do you even remotely imagine an amount of shit an XMPP client (say, a web client with no stored history) built on 'compatible' XEPs must do to display a telegram-like interface, with all the recent chats? How much time does it take? Best result we could achieve in our web version with 'compatible' server and 200 contacts is like 5 minutes. With our custom XEPs, it's currently down to 15-20 seconds, and our goal is to trim it to 3 seconds. Does it break anything with s2s? No. It only adds methods of how a client interacts with a server, that's it. Does it break legacy clients? No, they still can do it the old way, if someone is willing to wait 5 minutes.
Next, we have our group chats. They are powerful: archive search, moderation, anonymous mode, public mode, pinned messages, replies, mentions, extremely agile restriction/rights management. They are very easy to implement (on a client) and provide a nice fallback compatibility for any XMPP client even without support for them. You don't need support on participant server to use it (not as in MIX, to say). You can chat using multiple devices, with legacy clients alongside supporting clients, all working nicely with simple Carbons.
Documentation for all improvements is open, (it's not in english yet, but we're getting there), implementations are open-source and distributed under GNU licenses. No, I don't think your point about extending in incompatible ways is valid.
Probably, the more correct way to call it is that we are forking XMPP. Like, in git. We'll be sending XSF pull requests on every XEP we create - hopefully, one day XSF will come to their senses and see that their platform is fading into obscurity and irrelevance, and that to prevent it from happening they should do something differently.
I actually thought about using matrix, but it apparently "modern" means "resource hungry". My xmpp instance server runs on a small server with 2GiB Ram, with more than 1.5GiB being unused.
Than allowing for messaging or "social network"-like features?
From the user in practice, Matrix and XMPP (IM) are the same. These protocols might have made different technical choices but the user still only wants to send message and do various other things that both these protocol support. So not replicating all that data is actually a feature IMO.
It was not used by many people to talk outside of Google servers (federation ability went almost entirely unused), and it suffered from tons of inbound spam problems, so they shut it off.
To answer your question directly though, XMPP doesn’t seem to be that great of a protocol. I’ve heard repeatedly that implementing it is a big mess, and that XML was a poor choice. I’m not sure that this is the reason that users don’t use it, though. It could be that these days, the client-server model is mostly obsolete, as due to battery constraints, phone users mostly rely on Apple or Google push messages to notify.
1) not knowing what is supported on the server, or the other users server.
2) not handling mobile clients well (heavy battery use, weird deliverability issues.)
2 is BS with capital letters. See Converations and it's forks.
Did you ever wonder why there are no (to date) XMPP clients on iOS that are not complete and utter shit?
As a person who has first-hand knowledge of the matter, managing a team member tasked with the development of an iOS XMPP app (which is supposed to be NOT complete and utter shit), I tell you that creation of such app is impossible without reinvention of half of XMPP stack (basically every part that touches client-server interaction). Thankfully, s2s works rather fine in XMPP.
A phone user expects that messages would be displayed to him in notifications when received. One does not expect to be cut off communications because he had pressed a 'home' button, but it's what happens, and a user does not have any control to prevent it from happening.
To counter this and make XMPP work well on mobile and in browsers, we had to develop our own server and a bunch of new protocol extensions.
Real question: for email, I use K9, which supports IMAP Push, which, as far as I know, needs a live connection as well. Do you know if they are struggling as well, or is the xmpp push and imap push significantly different in some way?
Service -> Push service -> APNS / FCM -> Applications
With XMPP, servers act as 'service' from the scheme above, then relay a push initiation to 'Push service', maintained by a client app developers, Push service relays information to a respective service by Apple / Google, who deliver push to an Application, which connects to Service (or does not, pushes can contain all necessary information for displaying in notification, but that's a story for another time).
With email, I'm not really familiar with how IMAP Push works, but the scheme must be the same: an email server must relay info to a push service maintained by app developers, in your case, K9 guys.
From what I was able to gather after reading wikipedia for 5 min, an IMAP server upon receiving an email sends info to some 'mail user agent'. From wikipedia it's not really clear, but it appears that is is supposed to work on end devices. In this case, it won't really work as 'push'.
Google (or any other email provider, like Protonmail, who have their own app) get around this because they control both email server and push server, so it's trivial for them to initiate a push when an email is received.
XMPP server -> Push service -> APNS / FCM -> XMPP client.
Push service here is a service maintained by an XMPP client developers, cause you need a client app certificate to be able to send messages to it via APNS/FCM, and no sane devs will be handing out their certificates to third parties.
It should be noted, that the recent changes to how Apple push notifications work in iOS 13 (MORE restrictions on VoIP and 'silent' background notifications) require some updates to it, but so far, XEP-0357 does not look like something terrible.
With message archive management and message carbons there are no weird deliverability issues. I have not noticed battery issues with conversations running on several devices for the past couple years.
Yes, I'm full of anger. We had xmpp, pidgin, miranda, trillian. Now we have gazillion mobile only (no, a web gw through a server to your phone is NOT a desktop client) messaging, so let's throw matrix in to solve it, instead of building an xmpp client with up to date xep support. Xkcd 927 on steriods.