7 ms·

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

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.

infie 11y ago
Mind sharing which desktop client you use (and on which OS)?
- davecridland 11y ago
  I use Gajim on Linux and Conversations on Android, but the technology you're looking for is "XEP-0280: Message Carbons".
joepie91_ 11y ago
> 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 11y ago
  > 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_ 11y ago
    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 11y ago
  > 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 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.

infie 11y ago

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

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

joepie91_ 11y ago

> 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 11y ago
> 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_ 11y ago
  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 11y ago
> 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 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.