[Andrew_nenakhov]

As a person involved in XMPP development for over a decade, I can tell you why.

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.

[upofadown]

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

[Andrew_nenakhov]

1. We don't do embrace, extend and extinguish. All we do is open-source, with products available to download, and docs fully available.

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.

[arendtio]

How about Quicksy.im?

https://play.google.com/store/apps/details?id=im.quicksy.cli...

[Andrew_nenakhov]

Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this:

> a product, which can be easily deployed and will work consistently on every platform.

[arendtio]

Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-)

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 :-)

[Andrew_nenakhov]

> So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls.

Email [e-mail], 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!

[upofadown]

>This lead to great inconsistencies in implementations of even such basic functions like adding a contact.

How could anything an XMPP server do affect how a client adds a contact?

[comboy]

Any comment on the implementation Google did for hangouts/google talk? It seemed like that should have been enough of a push.

[Andrew_nenakhov]

GTalk was a rather nice XMPP implementation, it lacked some features like message archive, storing chat logs right in gmail instead (but then again, at the time there wasn't a good XEP for message archive).

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.