6 ms·

I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized an

I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.

dijit 7y ago
The issues mostly stem from: 1) not knowing what is supported on the server, or the other users server. 2) not handling mobile clients well (heavy battery use, weird deliverability issues.)
- pmlnr 7y ago
  1 can be queried. 2 is BS with capital letters. See Converations and it's forks.
  - Andrew_nenakhov 7y ago
    2 is not BS, but not for the given reasons (heavy battery use/weird deliverability issues). 'Not handling mobile clients well' is true. Did you ever wonder why there are no (to date) XMPP clients on iOS that are not complete and utter shit? As a person who has first-hand knowledge of the matter, managing a team member tasked with the development of an iOS XMPP app (which is supposed to be NOT complete and utter shit), I tell you that creation of such app is impossible without reinvention of half of XMPP stack (basically every part that touches client-server interaction). Thankfully, s2s works rather fine in XMPP.
    - jacob019 7y ago
      Perhaps Apple deserves some of the blame here? Is the protocol just too chatty?
      - ryukafalz 7y ago
        My understanding is it's because XMPP expects the client to be able to maintain a connection to the server, which is typically not possible on iOS. Apps on iOS are generally not permitted to run in the background, with a few limited exceptions.
        Andrew_nenakhov 7y ago
        Yes, exactly. And while currently there are ways to maintain a connection to a server on Android, it is clear that the platform is going to restrict this capability even further. Even now, if you run a background process, and start doing some memory-intensive operation, like taking a picture, your app is unceremoniously offloaded from memory, making you unable to receive messages, until the service permits a restart.
        rzzzt 7y ago
        But one could open and close a desktop XMPP app as well at arbitrary times. What is the difference?
        Andrew_nenakhov 7y ago
        The difference is control. A person knows that if he disables a desktop client, he won't be receiving any messages. A phone user expects that messages would be displayed to him in notifications when received. One does not expect to be cut off communications because he had pressed a 'home' button, but it's what happens, and a user does not have any control to prevent it from happening.
    - arendtio 7y ago
      How do Whatsapp et al. work differently on iOS than XMPP clients?
      - Andrew_nenakhov 7y ago
        XMPP problem is that in classical way a client needs to resume a stream. But to work well on iOS, an app must synchronize a state. WhatsApp is a heavily modified xmpp, and does just that. That's what it works so well. Such approach is way easier in a federated environment.
    - pmlnr 7y ago
      Ah. You were thinking ios as mobile. ios is not the only mobile. Xmpp is fine on android.
      - Andrew_nenakhov 7y ago
        Well, not really fine. You should trust me in this, because our Android xmpp app is closing on 2 million installations on Google Play. There are a lot of problems maintaining a persistent connection, and Google makes it harder with each new version of Android. And if we go for push notifications, without persistent connection, the problems are the same as with iOS. To counter this and make XMPP work well on mobile and in browsers, we had to develop our own server and a bunch of new protocol extensions.
        pmlnr 7y ago
        I believe there are problems, and a million thanks for maintaining clients. Real question: for email, I use K9, which supports IMAP Push, which, as far as I know, needs a live connection as well. Do you know if they are struggling as well, or is the xmpp push and imap push significantly different in some way?
        Andrew_nenakhov 7y ago
        Mobile OS pushes on both iOS (APNS) and Android (FCM) work the same: push can only be initiated by the developers of an application. So, no third-party server can push an app without intermediation by the application developers. Scheme is this: Service -> Push service -> APNS / FCM -> Applications With XMPP, servers act as 'service' from the scheme above, then relay a push initiation to 'Push service', maintained by a client app developers, Push service relays information to a respective service by Apple / Google, who deliver push to an Application, which connects to Service (or does not, pushes can contain all necessary information for displaying in notification, but that's a story for another time). With email, I'm not really familiar with how IMAP Push works, but the scheme must be the same: an email server must relay info to a push service maintained by app developers, in your case, K9 guys. From what I was able to gather after reading wikipedia for 5 min, an IMAP server upon receiving an email sends info to some 'mail user agent'. From wikipedia it's not really clear, but it appears that is is supposed to work on end devices. In this case, it won't really work as 'push'. Google (or any other email provider, like Protonmail, who have their own app) get around this because they control both email server and push server, so it's trivial for them to initiate a push when an email is received.
  - ajconway 7y ago
    Could you please expand on push notifications? So far I've only found https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html and it does not look great.
    - Andrew_nenakhov 7y ago
      Why, it works quite well. In short, the scheme is this: XMPP server -> Push service -> APNS / FCM -> XMPP client. Push service here is a service maintained by an XMPP client developers, cause you need a client app certificate to be able to send messages to it via APNS/FCM, and no sane devs will be handing out their certificates to third parties. It should be noted, that the recent changes to how Apple push notifications work in iOS 13 (MORE restrictions on VoIP and 'silent' background notifications) require some updates to it, but so far, XEP-0357 does not look like something terrible.
- jacob019 7y ago
  Servers most certainly do signal capabilities and extension support to clients, I do not have enough experience to comment on server-server signaling. With message archive management and message carbons there are no weird deliverability issues. I have not noticed battery issues with conversations running on several devices for the past couple years.
ralls_ebfe 7y ago
I moved to xmpp only for instant messaging over a year ago. At first it was met with great resistance by my contacts, but by now my family and almost every relevant friend installed conversations on their smartphone. I helped with the setup and provide them with access to my personal server. The growing public knowledge about privacy violations of the big services has made it very easy for others to grasp the reasoning behind my preference for decentralized services. I actually thought about using matrix, but it apparently "modern" means "resource hungry". My xmpp instance server runs on a small server with 2GiB Ram, with more than 1.5GiB being unused.
- Arathorn 7y ago
  Yes, Synapse is resource hungry - but it also does a lot more than a typical XMPP server. Meanwhile, we're finally making progress with small footprint homeservers for Matrix. shrug
  - ppjet6 7y ago
    > a lot more Than allowing for messaging or "social network"-like features? From the user in practice, Matrix and XMPP (IM) are the same. These protocols might have made different technical choices but the user still only wants to send message and do various other things that both these protocol support. So not replicating all that data is actually a feature IMO.
- thinkloop 7y ago
  From a privacy point of view, I would be more comfortable with google reading my messages than one of my buddies. Is your xmpp e2e?
  - pmlnr 7y ago
    Yes. It is. https://omemo.top/ https://omemo.top/
pmlnr 7y ago
Because then devs would need to follow rigorous standars with xml instead of "just building it". Yes, I'm full of anger. We had xmpp, pidgin, miranda, trillian. Now we have gazillion mobile only (no, a web gw through a server to your phone is NOT a desktop client) messaging, so let's throw matrix in to solve it, instead of building an xmpp client with up to date xep support. Xkcd 927 on steriods.
Andrew_nenakhov 7y ago
As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Also, it often happens that when a client developers need some feature that honestly should be done by a server, a developer still does this on a client, because it's all he has, with subpar results. Absent leadership from XSF also plays a role. This club now mostly cares about bureaucracy and following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there. That's why it is unlikely for any great product to appear under such guidance. We're trying a different approach, maybe we'll even succeed. If so, you'll hear about it on HN.
- arendtio 7y ago
  How about Quicksy.im? https://play.google.com/store/apps/details?id=im.quicksy.client&hl=en_US https://play.google.com/store/apps/details?id=im.quicksy.cli...
  - Andrew_nenakhov 7y ago
    Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this: > a product, which can be easily deployed and will work consistently on every platform.
    - arendtio 7y ago
      Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-) Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp. One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably. So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)
sneak 7y ago
Google made it practical and offered widespread federation. It was not used by many people to talk outside of Google servers (federation ability went almost entirely unused), and it suffered from tons of inbound spam problems, so they shut it off. To answer your question directly though, XMPP doesn’t seem to be that great of a protocol. I’ve heard repeatedly that implementing it is a big mess, and that XML was a poor choice. I’m not sure that this is the reason that users don’t use it, though. It could be that these days, the client-server model is mostly obsolete, as due to battery constraints, phone users mostly rely on Apple or Google push messages to notify.

dijit 7y ago

The issues mostly stem from: 1) not knowing what is supported on the server, or the other users server. 2) not handling mobile clients well (heavy battery use, weird deliverability issues.)

pmlnr 7y ago
1 can be queried. 2 is BS with capital letters. See Converations and it's forks.
- Andrew_nenakhov 7y ago
  2 is not BS, but not for the given reasons (heavy battery use/weird deliverability issues). 'Not handling mobile clients well' is true. Did you ever wonder why there are no (to date) XMPP clients on iOS that are not complete and utter shit? As a person who has first-hand knowledge of the matter, managing a team member tasked with the development of an iOS XMPP app (which is supposed to be NOT complete and utter shit), I tell you that creation of such app is impossible without reinvention of half of XMPP stack (basically every part that touches client-server interaction). Thankfully, s2s works rather fine in XMPP.
  - jacob019 7y ago
    Perhaps Apple deserves some of the blame here? Is the protocol just too chatty?
    - ryukafalz 7y ago
      My understanding is it's because XMPP expects the client to be able to maintain a connection to the server, which is typically not possible on iOS. Apps on iOS are generally not permitted to run in the background, with a few limited exceptions.
      - Andrew_nenakhov 7y ago
        Yes, exactly. And while currently there are ways to maintain a connection to a server on Android, it is clear that the platform is going to restrict this capability even further. Even now, if you run a background process, and start doing some memory-intensive operation, like taking a picture, your app is unceremoniously offloaded from memory, making you unable to receive messages, until the service permits a restart.
        rzzzt 7y ago
        But one could open and close a desktop XMPP app as well at arbitrary times. What is the difference?
        Andrew_nenakhov 7y ago
        The difference is control. A person knows that if he disables a desktop client, he won't be receiving any messages. A phone user expects that messages would be displayed to him in notifications when received. One does not expect to be cut off communications because he had pressed a 'home' button, but it's what happens, and a user does not have any control to prevent it from happening.
  - arendtio 7y ago
    How do Whatsapp et al. work differently on iOS than XMPP clients?
    - Andrew_nenakhov 7y ago
      XMPP problem is that in classical way a client needs to resume a stream. But to work well on iOS, an app must synchronize a state. WhatsApp is a heavily modified xmpp, and does just that. That's what it works so well. Such approach is way easier in a federated environment.
  - pmlnr 7y ago
    Ah. You were thinking ios as mobile. ios is not the only mobile. Xmpp is fine on android.
    - Andrew_nenakhov 7y ago
      Well, not really fine. You should trust me in this, because our Android xmpp app is closing on 2 million installations on Google Play. There are a lot of problems maintaining a persistent connection, and Google makes it harder with each new version of Android. And if we go for push notifications, without persistent connection, the problems are the same as with iOS. To counter this and make XMPP work well on mobile and in browsers, we had to develop our own server and a bunch of new protocol extensions.
      - pmlnr 7y ago
        I believe there are problems, and a million thanks for maintaining clients. Real question: for email, I use K9, which supports IMAP Push, which, as far as I know, needs a live connection as well. Do you know if they are struggling as well, or is the xmpp push and imap push significantly different in some way?
        Andrew_nenakhov 7y ago
        Mobile OS pushes on both iOS (APNS) and Android (FCM) work the same: push can only be initiated by the developers of an application. So, no third-party server can push an app without intermediation by the application developers. Scheme is this: Service -> Push service -> APNS / FCM -> Applications With XMPP, servers act as 'service' from the scheme above, then relay a push initiation to 'Push service', maintained by a client app developers, Push service relays information to a respective service by Apple / Google, who deliver push to an Application, which connects to Service (or does not, pushes can contain all necessary information for displaying in notification, but that's a story for another time). With email, I'm not really familiar with how IMAP Push works, but the scheme must be the same: an email server must relay info to a push service maintained by app developers, in your case, K9 guys. From what I was able to gather after reading wikipedia for 5 min, an IMAP server upon receiving an email sends info to some 'mail user agent'. From wikipedia it's not really clear, but it appears that is is supposed to work on end devices. In this case, it won't really work as 'push'. Google (or any other email provider, like Protonmail, who have their own app) get around this because they control both email server and push server, so it's trivial for them to initiate a push when an email is received.
- ajconway 7y ago
  Could you please expand on push notifications? So far I've only found https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html and it does not look great.
  - Andrew_nenakhov 7y ago
    Why, it works quite well. In short, the scheme is this: XMPP server -> Push service -> APNS / FCM -> XMPP client. Push service here is a service maintained by an XMPP client developers, cause you need a client app certificate to be able to send messages to it via APNS/FCM, and no sane devs will be handing out their certificates to third parties. It should be noted, that the recent changes to how Apple push notifications work in iOS 13 (MORE restrictions on VoIP and 'silent' background notifications) require some updates to it, but so far, XEP-0357 does not look like something terrible.
jacob019 7y ago
Servers most certainly do signal capabilities and extension support to clients, I do not have enough experience to comment on server-server signaling. With message archive management and message carbons there are no weird deliverability issues. I have not noticed battery issues with conversations running on several devices for the past couple years.

ralls_ebfe 7y ago

I moved to xmpp only for instant messaging over a year ago. At first it was met with great resistance by my contacts, but by now my family and almost every relevant friend installed conversations on their smartphone. I helped with the setup and provide them with access to my personal server. The growing public knowledge about privacy violations of the big services has made it very easy for others to grasp the reasoning behind my preference for decentralized services. I actually thought about using matrix, but it apparently "modern" means "resource hungry". My xmpp instance server runs on a small server with 2GiB Ram, with more than 1.5GiB being unused.

Arathorn 7y ago
Yes, Synapse is resource hungry - but it also does a lot more than a typical XMPP server. Meanwhile, we're finally making progress with small footprint homeservers for Matrix. shrug
- ppjet6 7y ago
  > a lot more Than allowing for messaging or "social network"-like features? From the user in practice, Matrix and XMPP (IM) are the same. These protocols might have made different technical choices but the user still only wants to send message and do various other things that both these protocol support. So not replicating all that data is actually a feature IMO.
thinkloop 7y ago
From a privacy point of view, I would be more comfortable with google reading my messages than one of my buddies. Is your xmpp e2e?
- pmlnr 7y ago
  Yes. It is. https://omemo.top/ https://omemo.top/

pmlnr 7y ago

Because then devs would need to follow rigorous standars with xml instead of "just building it". Yes, I'm full of anger. We had xmpp, pidgin, miranda, trillian. Now we have gazillion mobile only (no, a web gw through a server to your phone is NOT a desktop client) messaging, so let's throw matrix in to solve it, instead of building an xmpp client with up to date xep support. Xkcd 927 on steriods.

Andrew_nenakhov 7y ago

As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Also, it often happens that when a client developers need some feature that honestly should be done by a server, a developer still does this on a client, because it's all he has, with subpar results. Absent leadership from XSF also plays a role. This club now mostly cares about bureaucracy and following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there. That's why it is unlikely for any great product to appear under such guidance. We're trying a different approach, maybe we'll even succeed. If so, you'll hear about it on HN.

arendtio 7y ago
How about Quicksy.im? https://play.google.com/store/apps/details?id=im.quicksy.client&hl=en_US https://play.google.com/store/apps/details?id=im.quicksy.cli...
- Andrew_nenakhov 7y ago
  Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this: > a product, which can be easily deployed and will work consistently on every platform.
  - arendtio 7y ago
    Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-) Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp. One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably. So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)

sneak 7y ago

Google made it practical and offered widespread federation. It was not used by many people to talk outside of Google servers (federation ability went almost entirely unused), and it suffered from tons of inbound spam problems, so they shut it off. To answer your question directly though, XMPP doesn’t seem to be that great of a protocol. I’ve heard repeatedly that implementing it is a big mess, and that XML was a poor choice. I’m not sure that this is the reason that users don’t use it, though. It could be that these days, the client-server model is mostly obsolete, as due to battery constraints, phone users mostly rely on Apple or Google push messages to notify.