@lazarus @daniel #XMPP is still a thriving ecosystem with lots of good FOSS developers doing interesting things.

XMPP is also used under the hood in tons of products needing instant messaging even if they are not advertised as XMPP clients, or do not federate. But look at #Matrix, only 25% of matrix servers federate.

Anyway, all three share a strong focus on protocols, but there is a big difference: https://chatmail.at does not expose protocols to client developers, just a Rust SDK.

@daniel The big plus of #DeltaChat is that the infrastructure is already there. Infrastructure is a big part of the problem. And obviously using mail for that is only for people born before 2000.

Second is branding: When people hear #XMPP they hear 20 years of failure of implementing robust solutions both server-side and client-side. People just don't know that after 20 years there now are server and client solutions really working.

I consider this a failure on our part but I don’t really know what to do about it. Most arguments against #XMPP don’t hold if you’re building from scratch anyway:

• #Conversations_im looks very outdated: OK, but you are developing your own clients anyway.

• XMPP doesn’t have an SDK: Neither does your #ActivityPub or email stack

• OMEMO is insecure and I would prefer #MLS: Yes, let’s work on that together and you’ll still benefit from XMPP’s 100+ solved IM problems.

As a community, we often ask ourselves how to attract more users to #XMPP. Yet the real tragedy is that people would rather build something entirely new (loosely based on email or #ActivityPub) than consider XMPP. Need end-to-end encryption by default? If compatibility with existing XMPP clients is a secondary concern, you can implement it in your own solution while still benefiting from our two decades of experience in instant messaging.