That's one hell of a confused opinion.
That's just one example. To your credit, you managed to squeeze an impressive number of contradictions and non sequiturs in a very short space.
@61 Extremely fragmented.
Matching up XEPs for an adequate mobile experience is absolute insanity.
Not all XMPP servers support all XEPs. And you can't even tell what a single server supports for most of the XEPs.
On the IM client side of things, it's the same story. Until very recently, push support was basically non-existent, so XMPP mobile clients would keep an open TCP socket, wasting resources, and reconnecting on every connection change.
@61 In addition, XMPP simply was not designed with built-in encryption. Much like HTTP and E-Mail, and we had to add TLS, which for compatibility reasons, is optional. And for E2E, it's up to the client to support whatever they want. It really is a mess.
HTTP/2 fixes many of the problems of "classic" HTTP. Why can't XMPP evolve and stop being a dumpster fire of XEPs? That would be super cool.
But I was talking about transport encryption in this case. Like TLS for HTTP, XMPP can use TLS too, but it feels like a dirty hack rather than design use case.
Oh dear! 🙄
> Not all XMPP servers support all XEPs.
What part of “extensible” did you not understand?
> And you can't even tell what a single server supports for most of the XEPs.
What part of service discovery are you not aware of?
@61 I do not suggest replacing XMPP with Matrix. But even if I was, I'm referring to the IM part of XMPP.
Of course XMPP is that, and much more. There are many Internet services that use XMPP messaging, but you know very well that's not what people think about when they talk about XMPP. Lol.