4 ms·

Oh, sure. Pidgin has (unintentionally) done a lot of harm to XMPP in the past decade. It was a wildly popular client "back in the day", and even today it's stil

Oh, sure. Pidgin has (unintentionally) done a lot of harm to XMPP in the past decade. It was a wildly popular client "back in the day", and even today it's still often the only open-source IM app that comes to peoples' minds. However the project in general has had a general lack of resources for many years. Needless to say it did not keep up with the changing times. There's some renewed momentum in Pidgin recently, and I have hope that the situation will improve. But it is very far from a suitable recommendation for modern featureful messaging at this point.

theamk 5y ago
I don't think it's just pidgin. Let's pretend I want to get started on XMPP -- I just did "apt search xmpp".. my first results were coyim -- cannot find xep-0313 support, but [0] seems to indicate no? dino-im -- HEAD supports xep-0313 but Ubuntu's repo has "0.0.git20180130"... from [1] I think it should be fine too? ekg2-jabbel "0.4~pre+20120506.1" -- looks dead, but based on date, I guess no support empathy (part of GNOME): seems like no support? [2] So... 1/4 for initial sample. And I've had to resort to looking at source code in some cases to determine if this exists or not. Let's not blame pidgin -- most existing XMPP clients do not have offline message support. And if you want to set up a functional XMPP chat system, you have to start by reading forums and then do a bunch of manual compatibility tests on each platform you care about, as there is no guide anywhere on https://xmpp.org https://xmpp.org or any other official-looking places I could find. So it's no wonder that people choose Slack. Sure, it is primarily a web app, and the client is atrocious, but at least I am 100% sure that when my bot posts an report with an image and some buttons, everyone will be able to see and interact with that. [0] https://github.com/coyim/coyim/search?q=0313&type=commits https://github.com/coyim/coyim/search?q=0313&type=commits [1] https://github.com/dino/dino/commits/76e425ed2705349b201444e78719896419862b00/xmpp-vala/src/module/xep/0313_message_archive_management.vala https://github.com/dino/dino/commits/76e425ed2705349b201444e... [2] https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/36 https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/is...
- MattJ100 5y ago
  Well, this is a good demonstration of the "products vs protocols" issue that I actually wrote a blog post about: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ Much has been said about the staleness (or "stability") of Linux distro repositories. There's a reason you can't 'apt install slack', and this is one of them - many of the packages you quoted are years out of date. Secondly, there are a great many things that implement XMPP, and not all of them are suitable Slack replacements. It's unreasonable to expect that they would be (just like not everything that implements HTTP is suitable to use for daily browsing of the web). XMPP is similarly a protocol, not a product. To be clear I'm not saying it's your fault for starting with an "apt search", without a better idea of where else to start. That's part of the reason I'm advocating a slightly more product-led approach for XMPP these days. I'm personally focusing Snikket on personal messaging right now, so it's not a Slack replacement ( https://snikket.org/about/goals/ https://snikket.org/about/goals/ ). Luckily there are many open-source Slack alternatives these days (Rocket Chat, Mattermost, Element/Synapse). I think XMPP is further behind in this market. An XMPP-based solution would do well to use Converse.js or Movim, but that still leaves a whole lot of backend setup to deal with. For a custom solution with custom requirements it's great to have these composable building blocks available, but for a simple setup and onboarding experience, you're right - registering at slack.com wins hands-down :)
  - theamk 5y ago
    I think the biggest problem with XMPP is the lack of understanding of target audience, and lack of acknowledgement of past problems. Even in this discussion, you and zaik mentioned "XMPP" without any qualifications as viable messenger system. Anyone who reads those messages may try it, hit the old/low-featured client, and give it up forever, like our org did. If the goal to get more users to XMPP, starting with "Try Snicket, it implements right subset of XMPP" will work much better than just saying "XMPP". And in the ideal world, XMPP would embrace Compliance Suites -- the "getting started" page would mention a compliance level for each recommended client, the "features" page would list which features were added each year, and each project homepage would carry a large compliance level badge. Then in our conversation, you could just say "hey, you want Advanced Client 2016 or later, not the ancient stuff in the Ubuntu repos". Sadly, I don't think this will happen because I think XMPP is focused too much on low-featured clients.

theamk 5y ago

I don't think it's just pidgin. Let's pretend I want to get started on XMPP -- I just did "apt search xmpp".. my first results were coyim -- cannot find xep-0313 support, but [0] seems to indicate no? dino-im -- HEAD supports xep-0313 but Ubuntu's repo has "0.0.git20180130"... from [1] I think it should be fine too? ekg2-jabbel "0.4~pre+20120506.1" -- looks dead, but based on date, I guess no support empathy (part of GNOME): seems like no support? [2] So... 1/4 for initial sample. And I've had to resort to looking at source code in some cases to determine if this exists or not. Let's not blame pidgin -- most existing XMPP clients do not have offline message support. And if you want to set up a functional XMPP chat system, you have to start by reading forums and then do a bunch of manual compatibility tests on each platform you care about, as there is no guide anywhere on https://xmpp.org https://xmpp.org or any other official-looking places I could find. So it's no wonder that people choose Slack. Sure, it is primarily a web app, and the client is atrocious, but at least I am 100% sure that when my bot posts an report with an image and some buttons, everyone will be able to see and interact with that. [0] https://github.com/coyim/coyim/search?q=0313&type=commits https://github.com/coyim/coyim/search?q=0313&type=commits [1] https://github.com/dino/dino/commits/76e425ed2705349b201444e78719896419862b00/xmpp-vala/src/module/xep/0313_message_archive_management.vala https://github.com/dino/dino/commits/76e425ed2705349b201444e... [2] https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/36 https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/is...

MattJ100 5y ago
Well, this is a good demonstration of the "products vs protocols" issue that I actually wrote a blog post about: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ Much has been said about the staleness (or "stability") of Linux distro repositories. There's a reason you can't 'apt install slack', and this is one of them - many of the packages you quoted are years out of date. Secondly, there are a great many things that implement XMPP, and not all of them are suitable Slack replacements. It's unreasonable to expect that they would be (just like not everything that implements HTTP is suitable to use for daily browsing of the web). XMPP is similarly a protocol, not a product. To be clear I'm not saying it's your fault for starting with an "apt search", without a better idea of where else to start. That's part of the reason I'm advocating a slightly more product-led approach for XMPP these days. I'm personally focusing Snikket on personal messaging right now, so it's not a Slack replacement ( https://snikket.org/about/goals/ https://snikket.org/about/goals/ ). Luckily there are many open-source Slack alternatives these days (Rocket Chat, Mattermost, Element/Synapse). I think XMPP is further behind in this market. An XMPP-based solution would do well to use Converse.js or Movim, but that still leaves a whole lot of backend setup to deal with. For a custom solution with custom requirements it's great to have these composable building blocks available, but for a simple setup and onboarding experience, you're right - registering at slack.com wins hands-down :)
- theamk 5y ago
  I think the biggest problem with XMPP is the lack of understanding of target audience, and lack of acknowledgement of past problems. Even in this discussion, you and zaik mentioned "XMPP" without any qualifications as viable messenger system. Anyone who reads those messages may try it, hit the old/low-featured client, and give it up forever, like our org did. If the goal to get more users to XMPP, starting with "Try Snicket, it implements right subset of XMPP" will work much better than just saying "XMPP". And in the ideal world, XMPP would embrace Compliance Suites -- the "getting started" page would mention a compliance level for each recommended client, the "features" page would list which features were added each year, and each project homepage would carry a large compliance level badge. Then in our conversation, you could just say "hey, you want Advanced Client 2016 or later, not the ancient stuff in the Ubuntu repos". Sadly, I don't think this will happen because I think XMPP is focused too much on low-featured clients.