[davecridland]

The specific claims I was responding to when writing this (and it's still a draft) were an HTTP-based JSON protocol whose FAQ makes all these claims and more. And yeah, I think it's dumb to do things that way (both JSON/HTTP and making ill-informed and misleading comments in your FAQ).

As to your comments:

(1) I'm just not seeing this. Even without mobile-style push, apps like Conversations appear way down the list in Android. Note that because XMPP maintains a continuous TCP session (or WebSocket, or whatever), then you get "push" in a general sense; that is, there is no polling.

Using an XMPP client on your mobile will, of course, have an impact on battery life, but I don't think a good client will drain your battery. For me, Conversations uses less power than Solitaire according to Android.

(2) I'll agree that XML does make the development of XMPP libraries more complex, but we gain because it grants very simple permissionless extension capability, and that's hugely valuable. If developers working with (rather than on) XMPP are having to hit XML directly, that is absolutely a problem.

Finally, resources are the way they are for all sorts of reasons, but Message Carbons really does work for having conversation sync across multiple devices. I often walk away from my desktop and continue conversations on my mobile and/or tablet, and wander back to the desktop when I feel the need to continue with a keyboard.

Hope that helps.

[joepie91_]

> I'm just not seeing this. Even without mobile-style push, apps like Conversations appear way down the list in Android. Note that because XMPP maintains a continuous TCP session (or WebSocket, or whatever), then you get "push" in a general sense; that is, there is no polling.

> Using an XMPP client on your mobile will, of course, have an impact on battery life, but I don't think a good client will drain your battery. For me, Conversations uses less power than Solitaire according to Android.

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.

> (2) I'll agree that XML does make the development of XMPP libraries more complex, but we gain because it grants very simple permissionless extension capability, and that's hugely valuable. If developers working with (rather than on) XMPP are having to hit XML directly, that is absolutely a problem.

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.

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.

> Finally, resources are the way they are for all sorts of reasons, but Message Carbons really does work for having conversation sync across multiple devices. I often walk away from my desktop and continue conversations on my mobile and/or tablet, and wander back to the desktop when I feel the need to continue with a keyboard.

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.

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.

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.

[Flowdalic]

> 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.

You have to differentiate between the specification and the implemetation. Nothing in the XMPP specification prevents you from implementing a battery friendly XMPP client. But some implementations suck/have room for improvement.

[joepie91_]

Right. But when I have suggested a number of different XMPP clients to people, and every single one of them has caused this issue, then there's a problem.

Where that problem is, I don't know. I'm just going by what I hear from people more experienced with the effect of XMPP on battery life.

[davecridland]

> 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.

[dylz]

IMO, a lot of F/OSS seems to really ignore the UX/UI part. It doesn't seem to be just XMPP-community.

For another example, Mumble (VoIP) is effectively leader in bandwidth, quality, encryption, and extensibility - but have you ever tried to teach an end user gamer or otherwise about certificates, checking cert fingerprints, backing up their client certs so they don't lose admin privileges on servers, it's more or less a UX/onboarding clusterfuck.

[Flowdalic]

I don't think that aspect is intentionally ignored, it's just that most FOSS projects are seriously understaffed, and the UX/UI part is not a high priority item compared to getting it to work.

[joepie91_]

I think that's a mistake, though. Users often become contributors, and by offering a substandard UX, you remain forever understaffed - you don't gain the momentum, because you're not attracting users.

UX should be a high-priority item.

[mahyarm]

I guess thats when you build the client with good UX and charge for it. But it would have to be code under a license that is friendly to that kind of extension.

[nickpsecurity]

Good idea on charging for better interface. License might not be an issue, though. A cheat that many use is to run the GPL code in its own process, the proprietary one in its, and use a high-speed IPC method to marshal data between them. You can even do this as a pipeline with a proprietary UI on front, complex GPL in middle, and proprietary middleware as last step. Many models.

[joepie91_]

> 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.

I'm afraid that will never happen, though, due to the way extensibility is built into XMPP. HTTP is only very superficially extensible - you can provide custom headers (which are really just formatted strings) and custom-encoded body data. Both can be rather challenging to understand, in some cases, but the core protocol is easy to abstract, and usually is all you need.

For XML, that is much harder - without the right set of XEPs, XMPP isn't very useful for a real-world application. If only one single XEP is not implemented on your platform, you have to write your own, and immediately have to deal with the entirety of the XMPP/XML (protocol) design. You can't superficially string something together, like with a HTTP header.

> 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.

Things seem slightly more well-supported in Java-land, but in most other ecosystems, there are no implementations of XMPP that are both feature-complete and easy to use. A complex protocol invites developers who build complex abstractions, not easy ones.

> 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.

I have no idea, but some of my contacts use other clients, and they haven't gotten it to work either.

> For OTR, by the way, that just breaks with multi-device anyway. There's some experimental work with Axolotl underway which looks very promising.

Depends. XMPP seems somewhat lacking in its notification of which resources are 'active' (in common implementations), which is something that would help to at least synchronize online devices (by sending differently encrypted messages to different resources). Log synchronization is trickier, but really should be possible as well.

> 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.

I am not just refering to end-user UX, though - also to developer UX. Complex protocols with complex libraries aren't developer-friendly, and the same issue occurs as above: complex abstractions invite developers who write complex end user products.

It's very hard to get simple end user products built for complex protocols, because those require two fundamentally different types of developers.

> 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.

I think the big mistake there was to leave the exact registration data undefined. Rather, there should have been a standardization of 'common registration fields' (including eg. CAPTCHA data), and later amendment XEPs if things like CAPTCHAs were to have to change.

As it is, in-band registration is disabled almost everywhere, because no client can deal well with bot prevention measures.

[infie]

Mind sharing which desktop client you use (and on which OS)?

[davecridland]

I use Gajim on Linux and Conversations on Android, but the technology you're looking for is "XEP-0280: Message Carbons".