
The State of Mobile XMPP in 2016 - goffi
https://gultsch.de/xmpp_2016.html
======
Zash
XMPP is alright. It will never be perfect, but it keeps improving, and that's
important.

Personally I believe more in having people be in control of their own
communications than having ultra secure crypto. No crypto is going to help if
a single actor can see all metadata or decide who is allowed to communicate.

Therefore I strongly believe in federation and allowing everyone to choose
their client, service and server.

------
tfar
> But XMPP gives you another freedom. The freedom to choose your user
> experience. User experience describes the way we use something.

I don't think users care about the freedom to choose the UX. They just want a
good UX and that's it.

> Slack in turn fails to provide a decent mobile experience.

According the ratings of app stores, users are pretty happy with them.

> PGP has been around in the XMPP community for several years but is currently
> being reworked into a more modern extension called XEP-0374: OpenPGP for
> XMPP Instant Messaging that promises to make the onboarding easier for
> novice users.

I don't get how something OpenPGP will make onboarding any easier for XMPP.
New XMPP users who might have an automatically generated account somewhere,
still start with an empty contact list. Onboarding is definitely the _key_
issue for mobile XMPP.

------
mynameislegion
> XMPP just works everywhere. You only need one account to cater to all your
> instant messaging needs. If your workflow changes you just pick a different
> client.

AFAIK, this is painfully wrong and one of the main reasons XMPP struggles.
Nearly all of the modern 'messaging needs' are provided by the kind of XEPs
mentioned in the article. If you don't have an account with a server that
supports all of those XEPs, your needs will NOT be met. There is no easy way
to tell if your server supports them, either. The situation is atrocious from
a user perspective. As far as mass adoption is concerned, this puts XMPP so
far out of the league of centralized IM that it's eating twizzlers in the
parking lot.

There's a reason that everyone using Conversations essentially has to use a
server that is maintained by the developers. Otherwise, most of the XMPP
featureset they offer simply doesn't work. This lack of homogeneity between
servers means users pile up in the 'better' servers, which is apparently the
opposite of what federation is supposed to achieve (?).

What if you want the freedom to switch from the Conversations server to a
different public server but maintain the same feaureset? Good luck with your
Google searches. Keep a table of your relevant XEPs nearby!

I think there needs to be incentive built into the protocol for all servers to
maintain a baseline of XEP parity. In it's current state there is absolutely
no way to convince the average user of XMPP's superiority. The experience is
far too inconsistent. At least Matrix can provide a clean slate.

~~~
Zash
> There is no easy way to tell if your server supports them, either.

False. XMPP has excellent feature negotiation capabilities.

> everyone using Conversations essentially has to use a server that is
> maintained by the developers

No, you just need to use a server maintained by someone who actually maintains
it.

> Otherwise, most of the XMPP featureset they offer simply doesn't work.

Feature negotiation and graceful fallback, is it really that hard?

> I think there needs to be incentive built into the protocol for all servers
> to maintain a baseline of XEP parity

Incentives, yes. In the (core) protocol? No. I think publishing a new "XMPP
Compliance Suite $year" XEP is better than throwing the entire thing out, in a
couple of years when everyone suddenly wants a different feature set.

> At least Matrix can provide a clean slate.

A clean slate which will be obsolete in just a few years, and will have to be
invented from scratch all over again.

~~~
Arathorn
I'd be surprised if Matrix is obsolete in a few years. The difference between
the Matrix and XMPP spec structure is simply that Matrix is a single curated
monolithic spec rather than a set of XEPs. So there's only one true standard
at any given point, at a given version (unless someone forks it). We've been
evolving it quite rapidly so far, adding modules for the various different use
cases out there
([http://matrix.org/docs/spec/client_server/r0.1.0.html#featur...](http://matrix.org/docs/spec/client_server/r0.1.0.html#feature-
profiles)), and I don't see that rate of evolution slowing down any time soon.

And even if we did go and entirely rearchitect Matrix (e.g. making it entirely
P2P, which is certainly a thought experiment we keep in mind), one would just
go bridge it into the existing Matrix ecosystem and migrate as desired.

~~~
emias
> We've been evolving it quite rapidly so far, adding modules for the various
> different use cases out there [...], and I don't see that rate of evolution
> slowing down any time soon.

> And even if we did go and entirely rearchitect Matrix (e.g. making it
> entirely P2P, which is certainly a thought experiment we keep in mind), one
> would just go bridge it into the existing Matrix ecosystem and migrate as
> desired.

Are you saying you might end up in a situation where "fragmentation of
features between clients and servers is common"?

------
davecridland
A device-global push protocol isn't entirely useless, since the device OS can
wake all the clients at once if it needs to, synchronizing network activity.
But I agree it's a significant overhead if you're able to just hold open the
TCP session, as well as concentrating yet more information into a single
entity you don't get to choose.

~~~
inputmice
Push messages on GCM are going through immediately. The push server is not
queuing up messages to send them all at once. I admit that could be helpful
but Google is not doing this either.

The alarm manager - where apps can schedule to be run at some point in the
future - is in fact grouping those events together. But that happens entirely
independent of GCM. The Alarm Manager is part of Android where as the push
service is a proprietary Google service.

~~~
davecridland
Oh, okay - in that case I slouch corrected.

