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 4 days ago | parent | next [-]

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/

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.

▲ styanax 4 days ago | parent | prev | next [-]

> but I blame the "everything is an extension" model ...

100%. If you're not keen on self-hosting and want to use any one of the many, many public servers this becomes such a pain, and leads to the same "decision deadlock" trying to get friends to join Mastodon or Lemmy ("which one do I want? there are so many, how do I know if it's good"). Because this is a thing:

    https://compliance.conversations.im/

"Hmmm, does xyz.com support XEP-1234 for message archiving?" or whatever it is; there's a real uphill social battle unless you make those choices for your friends to get started. While Signal is not perfect, it's easy onboarding without confusing XEP which-server choices for the average human. $0.02 I struggle to get people on Signal as it is.

Edit: found it, it's XEP-0313 and only 92% of public servers support it. Only 86% support Push Notifications, 94% OMEMO. One can argue server operators have disabled them but it points back to decision deadlock.

▲

zaik 3 days ago | parent [-]

There is also Quicksy.im which offers Signal style onboarding and contact discovery but you also get a routable XMPP address.

▲

styanax 2 days ago | parent [-]

95% XEP feature coverage. https://compliance.conversations.im/server/Quicksy.im/

	▲	zaik a day ago \| parent [-]
		Quicksy is run by the same guy who developed Conversations and this compliance test btw. It will work for its target audience. If you know what a XEP is, you don't need Quicksy.

▲ Flowdalic 4 days ago | parent | prev [-]

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

▲

lmm 4 days ago | parent | next [-]

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

You can call the kind of optionality that those kind of protocols have "extensions" if you want, but it's a lot more lightweight than the kind of extensibility that XMPP was designed around, which is the thing that I'm arguing did more harm than good.

▲

tcfhgj 4 days ago | parent | prev [-]

Optional features is something different than uncoordinated extensions which might conflict with each other.

▲

Flowdalic 4 days ago | parent [-]

I am not sure if I would phrase it that way.

(Seemingly) conflicting extensions are another consequence of the loosely coupling between standardization and implementations. In addition, the emergence of several functionally overlapping extensions is stimulated by the freely accessible standardization process.

Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.

▲

tcfhgj 4 days ago | parent [-]

> Especially in the early phase of an extension, you want to encourage experimentation with different approaches. Early selection would be disadvantageous.

With any standard you can experiment what you want, nobody* even can prevent you from doing it no matter how inaccessible the standardization process is.

The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem.

What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components?

Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat)

*okay technically not correct. Law can e.g. decide making e2ee illegal technology and criminalize even playing around with it.

	▲	Flowdalic 4 days ago \| parent [-]
		> The standardization process comes into play when you think you have found a good solution, which should be adopted by THE standard respectively the ecosystem. Na, the standardization process starts much earlier. Using the example of the IETF process, after which XMPP standardization process is largely modeled: standardization starts when you submit an I-D to IETF and/or approach an IETF WG. > What matters is what the standard itself looks like, do you have a coherent specification which specifies the current way of doing things, including optional components? Or do you have a set of independent ways of doing it, because the standardization process doesn't actually decide what is the correct way of doing something (e.g. managing a group chat) Well put and I totally agree (I think no one would have a reason to disagree with that statement).