> I don't know how accurate Android's power estimates are, but I consistently have people telling me that they are switching back to proprietary messengers because every XMPP client they've tried drained their battery. Whatever causes it, there's a real problem here.
I honestly cannot help you. Could be that my usage patterns just happen to make the battery usage better (though I'm a heavy user of multiple accounts), or could be I'm a really serious Solitaire player.
I do know that over the past year or so the situation has really improved, though (mostly with the merging of aSmack and Smack, but Conversations too).
> The problem is that theoretical future benefits are worthless if you never get a base implementation going. XMPP is just too hard for many developers - it's not a thing that you're going to understand well unless you work on it full-time, and that's not acceptable for a protocol.
I mostly agree; I'd hope that we could get to a place where the requirement to "know" XMPP was roughly that of needing to "know" HTTP. So simple use cases could be done without truly understanding the guts.
> Hitting XML directly is almost always a requirement. Libraries are woefully incomplete due to the large number of XEPs, and to implement anything yourself, you must understand the XML structure.
> If the intention of XMPP or XMPP frameworks was to abstract away the XML, then they have failed.
I'll confess to not being your typical XMPP developer, but I was under the impression that successfully hitting the XML with libraries like Smack was actually quite hard.
> I experience constant issues with OTR, most servers don't seem to even support message carbons (nor do major clients like Pidgin have any useful indications of it), and frankly, I have never seen a single 'regular' user get synchronization set up correctly.
OK, so Pidgin is a multi-protocol client which means the UI is abstracted out... But... https://developer.pidgin.im/ticket/15508 I don't understand their logic there, I have to say.
For OTR, by the way, that just breaks with multi-device anyway. There's some experimental work with Axolotl underway which looks very promising.
> This is really a pervasive problem in the XMPP ecosystem: everything is too hard. Little to no thought seems to have gone into the UX, and unless you are an 'experienced XMPP user', you really have no clue what is going on. The experienced users say "meh, works for me" and don't set out to fix it.
I won't disagree there. The lack of a consensus on UX considerations (in fact, the lack of any attempt to get such a consensus) means that different clients present even simple things like jids differently. That's something the community (or the XSF) could seek to address.
> This is true for the frameworks, the clients, and most of the servers. It's just all-around user-hostile, and that needs to change.
And again, I agree. It's sad, especially, that you qualify servers yet not the clients - I'd rather see clients as really easy. I mostly think Conversations is there, mind, but I'm hardly the target audience here.
That said, I'm aware that one key problem faced by a federated network is that client on-boarding can't, so easily, create your account for you, and early attempts to streamline that process have left serious abuse problems in their wake.