Correct, it's been possible for many years. What's generally the case is that people complaining about things like this are still using/remembering software that hasn't changed much in the last decade. Common culprits are Pidgin and Adium (both based on libpurple) which, while still developed, is lacking many modern features. I'm hoping that will change, but it's subject to the usual economics of open-source.

XMPP is between a group of people who complain that it is stuck in the past (i.e. they think it still only supports the features it supported in 2008) and another group of people who complain the opposite - that it has "too many XEPs" (this is due the fact that XMPP evolves through a mechanism of creating and deprecating extensions to the core protocol). In reality the XSF annually publishes the current list of recommended XEPs for different use cases (see https://xmpp.org/about/compliance-suites/ ) and the XEPs for multi-device messaging have been part of this set for many years, and are implemented in practically every actively maintained XMPP client.

Pointing at XEPs is the problem with Jabber and Jabber advocacy.

Point at mature clients and servers that robustly implement those XEPs.

Whats the functioning and mature chain of shared conversation state for android/server/linuxclient for example?

In 2017ish that didn't really exist, even xep-0313 was published first in 2012.

https://xmpp.org/extensions/xep-0313.html#appendix-revs

I have no idea what works in 2022, my problems were solved from the beginning because Matrix did the right thing originally.

(Hilariously this is kind of POP3 vs IMAP all over again on some level...)

Ironically, Matrix MSCs will have the same exact “problem” of “too many extensions”.

No, the whole point of MSCs is that they aren't part of the protocol - they are just random proposals for new ideas; the more the merrier. The protocol doesn't have extensions.

When an MSC makes it through the process, it is added to the protocol, right?

Then all the servers and clients need to implement those MSCs or else they are not compliant with the protocol.

Either you're not compliant with the protocol (Matrix), or you're not compliant with a certain extension (XMPP).

I don't understand how these are different. Matrix has a lot of non-compliant servers and clients. XMPP has a lot of servers and clients that don't implement certain extensions.

> When an MSC makes it through the process, it is added to the protocol, right?

Yes.

> Then all the servers and clients need to implement those MSCs or else they are not compliant with the protocol.

It's no longer a MSC at that point; it's part of the next versioned release of the protocol. So yeah, if the feature profile their client/server is targeting doesn't implement the required features from that version of the protocol, it's not compliant.

> Either you're not compliant with the protocol (Matrix), or you're not compliant with a certain extension (XMPP).

> I don't understand how these are different. Matrix has a lot of non-compliant servers and clients. XMPP has a lot of servers and clients that don't implement certain extensions.

The difference is that in Matrix there's only one specification which servers & clients can be compliant or not compliant with. Whereas in XMPP, there's an arbitrary combinatoric explosion of XEPs which you may or may not be compliant with.

> The difference is that in Matrix there's only one specification which servers & clients can be compliant or not compliant with. Whereas in XMPP, there's an arbitrary combinatoric explosion of XEPs which you may or may not be compliant with.

We don't version XMPP in this way, but instead annually publish the "compliance suites" listing the required XEPs for a range of profiles: https://xmpp.org/about/compliance-suites/ - so for example an XMPP client can be compliant with the 2021 mobile requirements. In this document we also hint to developers which XEPs are looking promising for the future, so they have ample notice to play with them and give feedback.

Beyond the compliance suites, implementations are obviously free to experiment with other XEPs, and that experimentation feeds into the standards process and determining what will be in the following year's compliance suite.

iirc, MAM doesn't work with encryption and depends on support by the server a specific room is hosted on (duration and availability)