The State of Mobile XMPP in 2016
gultsch.de
gultsch.de
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.
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.
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.
There's no simple answers to this. I can tell you it's absolutely not a protocol issue - the protocol issues are ensuring graceful degradation remains possible during advances, which XMPP does well - but a political one. Profile specifications, which indicate groups of XEPs which the community expects to be supported, are part of this. Certification might also need to happen. Maybe monetary awards, even.
One of the biggest things currently driving server implementors to get the XEP support, and server maintainers to deploy it, though, is folk like inputmice driving the market with Conversations.
Matrix has a shot because it's consistent right now. If they stay consistent, they will have an even larger shot.
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.
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.
> 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"?
> False. XMPP has excellent feature negotiation capabilities.
User don't care what the protocol can do. "How come persistent group chat isn't working? Ah, I'll just use WhatsApp"
> Feature negotiation and graceful fallback, is it really that hard?
This is dependent on the client. Does your client support that? Who knows? Users don't care about any of this.
> Incentives, yes. In the (core) protocol? No.
There's no greater incentive for public server providers than the danger of having their user base get isolated from the rest of the network. That can be done through the protocol and is the only incentive that will actually _accomplish_ anything.
That is completely untrue. First of all there are public servers that have exactly the same feature set like jabber.at second of all we are running ejabberd on conversations.im. ejabberd is open source can be run by anyone. You just have to do it. Granted the list of public servers with a full feature set is not as long as we'd like. But the best way of changing this is to run one yourself.
1) They're not going to run their own server.
2) They're not going to bother researching which servers support Conversations entire featureset.
That's why XMPP is garbage for the majority users and why XMPP weenies will stay baffled as to why there aren't a flood of users using it.
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.