5 ms·

That's quite unspecific and unhelpful. Personally I find XMPP much makes sense. Sure it's this weird streaming XML thing, but there's a request/response patter

That's quite unspecific and unhelpful. Personally I find XMPP much makes sense. Sure it's this weird streaming XML thing, but there's a request/response pattern (IQ) inside that seems fine. I love how nicely it composes: accounts have a tree of nodes they can define for whatever content they want, which is a sensible & flexible base. Then there's pubsub, and ACL capability specs on top of that. Everything stacks relatively sensibly. The past decade has seen some good XMPP Enhancement Protocols (XEP) to create best practices & recommended feature sets. It was such a small jump to create a full "everything app" atop XMPP baseline capabilities: > Libervia [ed: nee Salut-a-Too] is a all-in-one tool to manage all your communications needs: instant messaging, (micro)blogging, file sharing, photo albums, events, forums, tasks, etc. https://libervia.org/ https://libervia.org/ It's unfortunate that the top rated comment is uncontestable blanket desparagement. Can we raise this from a low criticism to something respect-worthy?

icedchai 1y ago
I wasn't trying to be specific, just an opinion on what I experienced 10+ years ago. Others are welcome to work with the protocol and develop their own opinions.
- hackyhacky 1y ago
  If your opinion is based on concrete experience, you could help people understand your position by sharing the specific aspects of XMPP that you dislike. An opinion without evidence or reasoning is not a valuable contribution to the conversation.
  - tcfhgj 1y ago
    My opinion: XMPP is too little like Matrix (e.g. decentralized rooms, people as verification targets, messages (incl. e2ee ones) easily synced to all sessions) while Matrix is in a sub optimal state due to the Element/Element X client split
  - icedchai 1y ago
    It's been well over 10 years since I worked with, almost 15. I remember issues with keeping multiple devices in sync, syncing them back up when a user comes back online, especially with multiuser chats. I understand that is probably better now, with carbons and archiving XEPs. In general, it felt like, XMPP has too many "optional" features. The core protocol is tiny, but everything you need and want to make it useful is optional.
- wink 1y ago
  Don't worry, every single one of these discussion is a dozen fanboys trying to convince us that our problems back then weren't real :/ (JFTR, was a relatively happy user amongst fellow nerds & family until everyone just stopped using it, and also usage on mobile was terrible on early smart phones and fixed much too late)
Bjartr 1y ago
In today's world of containerization and AI powered UI automation, perhaps a single user-facing client could be viable again, powered by hidden per-service clients under the hood. Where each services' UI state is continually monitored and interacted with by an AI directed by user interactions in the visible interface. That would be against the services' ToS probably, but it could work I think. Who needs APIs when a computer can exploit the analog hole and use the same affordances as a human?
- edoceo 1y ago
  A "User-Agent" if you will.
- zamadatix 1y ago
  I don't think having a single user-facing client has ever really been held back by the technology. It's always the services being intentionally proprietary, intentionally breaking 3rd party clients, and ToSs making it risky to do.
  - wink 1y ago
    I mean, different platforms exist just the same as back then. Windows, Linux, Android, iOS (and let's say some nerds will make it work on osx and the BSDs from the linux version). That was a problem back then and it's a problem right now
    - zamadatix 1y ago
      There have always been approaches to multi platform apps, the limitations attempts at this (both in the past and currently) have repeatedly been a great UI with hostile 3rd party services.
oofbey 1y ago
Here's a specific complaint about XMPP, and possible explanation why nobody uses it any more. (I worked on a large-scale XMPP implementation back in the day.) Presence. That's the colored dots indicating "is somebody online or not". The traffic needed to maintain presence scales by N^2, and in any large-scale implementation, the traffic to maintain presence data completely dominates anything useful. Not to mention that for the past 15 years or so (ever since everybody has a connected cell-phone all the time) the whole idea of presence (am I online or not?) is either meaningless or just badly modeled. So the result is a protocol which spends tons of bandwidth and battery maintaining metadata that is functionally useless. That's why the real world has run away from it as fast as possible.
- eurleif 1y ago
  >The traffic needed to maintain presence scales by N^2 Only true if we assume the average number of contacts scales linearly with the total number of users, right? But then, we could also assume that the average number of messages that a given user sends scales linearly with the total number of users, in which case the amount of traffic needed to transmit messages also scales by N^2. A couple of easy fixes: cap the number of contacts at some large constant (as many services do), or just disable presence information altogether in your implementation. I'm skeptical that this played a major role in XMPP's lack of popularity, especially because e.g. WhatsApp and Facebook Messenger have presence information, and are still popular.
lmm 1y ago
XMPP missed the boat largely because it couldn't handle multiple clients correctly for years - the default is to deliver messages to one of your clients, you need an extension to do the sensible thing, and that extension spent years in bikeshed limbo right as smartphones were taking off and people started wanting to use the same messenger on their phone and computer at the same time. (I've heard that performance/battery issues from XML validation didn't help either) Personal speculation but I blame the "everything is an extension" model - it was meant to reduce fragmentation and allow clients with different featuresets to interoperate, but in practice adding a new XEP seems to have all the downsides of making a change to a non-extension-based standard (you still have to get all the clients to agree) and none of the upsides.
- jauntywundrkind 1y ago
  This kind of checks out for me. But also, there have been decent protocols around this for a long time, that many clients & servers have implemented. From Multi-device in the excellent Modern XMPP:* > XEP-0280: Message Carbons - for "live" synchronization of conversations between online devices. XEP-0313: Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline https://docs.modernxmpp.org/client/protocol/ https://docs.modernxmpp.org/client/protocol/ The XEP-0313 spec dates back to 2012 which is less old than I expected, and that's only the 0.1. So, very fair point. More generally, the above complaint was about the development experience of XMPP. I feel somewhat like complaining about XMPP being failed is well tread from a why consumers didnt adopt it view, that negative sentiment abounds & everyone is more than happy to cast blame as to why. I've seen a lot less complaints about the development experience, and felt like maybe there was some novel fruitful grounds that a more developer-centric view might have been able to open up.
- Flowdalic 1y ago
  > Personal speculation but I blame the "everything is an extension" model - it was meant to reduce fragmentation and allow clients with different featuresets to interoperate I could be wrong, but that reads like you suggest that there is an alternative to the "extension model". However, any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions. Think about protocols like SMTP and DNS—each has a foundational core that’s been expanded upon by numerous optional features.

icedchai 1y ago

I wasn't trying to be specific, just an opinion on what I experienced 10+ years ago. Others are welcome to work with the protocol and develop their own opinions.

hackyhacky 1y ago
If your opinion is based on concrete experience, you could help people understand your position by sharing the specific aspects of XMPP that you dislike. An opinion without evidence or reasoning is not a valuable contribution to the conversation.
- tcfhgj 1y ago
  My opinion: XMPP is too little like Matrix (e.g. decentralized rooms, people as verification targets, messages (incl. e2ee ones) easily synced to all sessions) while Matrix is in a sub optimal state due to the Element/Element X client split
- icedchai 1y ago
  It's been well over 10 years since I worked with, almost 15. I remember issues with keeping multiple devices in sync, syncing them back up when a user comes back online, especially with multiuser chats. I understand that is probably better now, with carbons and archiving XEPs. In general, it felt like, XMPP has too many "optional" features. The core protocol is tiny, but everything you need and want to make it useful is optional.
wink 1y ago
Don't worry, every single one of these discussion is a dozen fanboys trying to convince us that our problems back then weren't real :/ (JFTR, was a relatively happy user amongst fellow nerds & family until everyone just stopped using it, and also usage on mobile was terrible on early smart phones and fixed much too late)

Bjartr 1y ago

In today's world of containerization and AI powered UI automation, perhaps a single user-facing client could be viable again, powered by hidden per-service clients under the hood. Where each services' UI state is continually monitored and interacted with by an AI directed by user interactions in the visible interface. That would be against the services' ToS probably, but it could work I think. Who needs APIs when a computer can exploit the analog hole and use the same affordances as a human?

edoceo 1y ago
A "User-Agent" if you will.
zamadatix 1y ago
I don't think having a single user-facing client has ever really been held back by the technology. It's always the services being intentionally proprietary, intentionally breaking 3rd party clients, and ToSs making it risky to do.
- wink 1y ago
  I mean, different platforms exist just the same as back then. Windows, Linux, Android, iOS (and let's say some nerds will make it work on osx and the BSDs from the linux version). That was a problem back then and it's a problem right now
  - zamadatix 1y ago
    There have always been approaches to multi platform apps, the limitations attempts at this (both in the past and currently) have repeatedly been a great UI with hostile 3rd party services.

oofbey 1y ago

Here's a specific complaint about XMPP, and possible explanation why nobody uses it any more. (I worked on a large-scale XMPP implementation back in the day.) Presence. That's the colored dots indicating "is somebody online or not". The traffic needed to maintain presence scales by N^2, and in any large-scale implementation, the traffic to maintain presence data completely dominates anything useful. Not to mention that for the past 15 years or so (ever since everybody has a connected cell-phone all the time) the whole idea of presence (am I online or not?) is either meaningless or just badly modeled. So the result is a protocol which spends tons of bandwidth and battery maintaining metadata that is functionally useless. That's why the real world has run away from it as fast as possible.

eurleif 1y ago
>The traffic needed to maintain presence scales by N^2 Only true if we assume the average number of contacts scales linearly with the total number of users, right? But then, we could also assume that the average number of messages that a given user sends scales linearly with the total number of users, in which case the amount of traffic needed to transmit messages also scales by N^2. A couple of easy fixes: cap the number of contacts at some large constant (as many services do), or just disable presence information altogether in your implementation. I'm skeptical that this played a major role in XMPP's lack of popularity, especially because e.g. WhatsApp and Facebook Messenger have presence information, and are still popular.

lmm 1y ago

XMPP missed the boat largely because it couldn't handle multiple clients correctly for years - the default is to deliver messages to one of your clients, you need an extension to do the sensible thing, and that extension spent years in bikeshed limbo right as smartphones were taking off and people started wanting to use the same messenger on their phone and computer at the same time. (I've heard that performance/battery issues from XML validation didn't help either) Personal speculation but I blame the "everything is an extension" model - it was meant to reduce fragmentation and allow clients with different featuresets to interoperate, but in practice adding a new XEP seems to have all the downsides of making a change to a non-extension-based standard (you still have to get all the clients to agree) and none of the upsides.

jauntywundrkind 1y ago
This kind of checks out for me. But also, there have been decent protocols around this for a long time, that many clients & servers have implemented. From Multi-device in the excellent Modern XMPP:* > XEP-0280: Message Carbons - for "live" synchronization of conversations between online devices. XEP-0313: Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline https://docs.modernxmpp.org/client/protocol/ https://docs.modernxmpp.org/client/protocol/ The XEP-0313 spec dates back to 2012 which is less old than I expected, and that's only the 0.1. So, very fair point. More generally, the above complaint was about the development experience of XMPP. I feel somewhat like complaining about XMPP being failed is well tread from a why consumers didnt adopt it view, that negative sentiment abounds & everyone is more than happy to cast blame as to why. I've seen a lot less complaints about the development experience, and felt like maybe there was some novel fruitful grounds that a more developer-centric view might have been able to open up.
Flowdalic 1y ago
> Personal speculation but I blame the "everything is an extension" model - it was meant to reduce fragmentation and allow clients with different featuresets to interoperate I could be wrong, but that reads like you suggest that there is an alternative to the "extension model". However, any solution where standardization and implementations are independent entities, and thereby experience a sufficient degree of freedom, will have a trajectory to a situation where you have a robust core specification and optional extensions. Think about protocols like SMTP and DNS—each has a foundational core that’s been expanded upon by numerous optional features.