"""
This is how Matrix solved my problems right away and why XMPP never actually understood or cared about my problems.
I want all my messages and history on all my devices wherever I login with the proper credentials.... not a handwavey reference to 3 different ways to implement that with 9-15 different XEP combinations which noone has done yet.
TLS/crypto and the federation on top are great/mandatory but Matrix solved the core problem first and thats what matters.
Thanks again btw :)
Is this not possible with XMPP? Genuine question. I thought there were recent XEPs for standardized handling of message history (including export/import).
edit: it’s here https://xmpp.org/extensions/xep-0313.html#intro
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.
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...)
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.
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.
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.
Also I hope you have most of this as a copypasta so time isn't wasted responding to the 1000th matrix FUD post.
Though XMPP and Matrix are diametrically opposed in terms of their protocol semantics, and can be meant to occupy different use-cases at their edges (say, message passing vs. eventually-consistent data stores), their core use-cases are much the same: one-to-one and many-to-many messaging for both public and private groups, in competition with other, proprietary applications occupying the same space (e.g. Slack, Signal, Telegram, Discord). For sure, it might be agreed that there's a wide spectrum of difference even in the aforementioned proprietary applications (the whole banquets and barbecues notion), but I'm hoping it's not controversial to think that one can implement an application in the same UX vein as the proprietary alternatives using either XMPP and Matrix.
That, I feel, the the core of the contention -- that somehow Matrix has wrested focus/effort/velocity away from a still-viable project in terms of end-user-goals, thus somehow dooming it (or open-source/community-owned messaging in general) in the process. At face value, this might very well be nonsense; if XMPP cannot compete, or is not viable, nothing anyone outside the project does will affect this fact. Conversely, if Matrix didn't exist in its current form, it might not exist at all -- it's not a foregone conclusion that efforts would've been poured into XMPP or whatever else instead. In any case, competition is generally thought to be a good thing, insofar as it helps drive competitors to improve.
Emotionally, though, I think I understand the contention, and I've seen it happen not with protocols, but with things like Linux distributions, where people would lament the proliferation of disjoint efforts, where no clear, viable contender to the proprietary solutions existed at the time -- and some might argue does not exist still; nevertheless there's not much lamenting nowadays, where multiple viable distributions and desktop environments exist.
In some sense, community-owned messaging is still in a precarious state, and splitting up efforts, as it were -- since efforts are not just split in protocol implementation, but also in the ecosystem of applications etc. -- makes it feel even more precarious. Whether there's any rational basis to this, and whether either protocol has a technical advantage over the other, I don't know.
It's like saying "Why have Canvas, when we already have SVG?". Or "Why have NNTP, when we already have mailing lists"? Or "Why have Git when we have Subversion"? Or "Why have Linux when we already have BSD"?
The projects are diametrically opposite in their most fundamental ways - with the sole exception that they can both be used for instant messaging. Just like SVG and Canvas both render graphics, and NNTP & SMTP can both be used for discussion forums, and Git & SVN both manage source code. They have completely different tradeoffs; one is not necessarily better or worse than the other; they are just utterly different approaches and can and should coexist based on folks' preferences and requirements.
* Matrix is a decentralised conversation history replication protocol, not a messaging protocol. Architecturally it has no concept of direct messages or store-and-forward messaging for IM; instead everything is a group conversation with a conversation history getting replicated between servers (and their clients). Conversely, XMPP is a message passing system (although it's true you could layer a DAG-based conversation database on top in a XEP, at the expense of compatibility with the rest of XMPP). It's literally the difference between NNTP (Matrix) and SMTP+IMAP (XMPP).
* Matrix is a single monolithic spec, defining precisely what features exist for a given stable release. New features are proposed as PRs to the spec (MSCs), often with competing options, but only one gets ratified and merged. Conversely, XMPP is a cloud of XEPs, with compatibility XEPs published occasionally.
There are obviously other differences (e.g. Matrix mandating E2EE for private conversations (https://matrix.org/blog/2020/05/06/cross-signing-and-end-to-...), XML v. JSON etc) but the two points above are the fundamental differences which mean that you wouldn't be able to build Matrix on XMPP short of effectively creating a new protocol - at which point you've effectively built Matrix anyway.
This said, there are also some similarities which often get misrepresented or misunderstood:
* Both protocols are extensible. In Matrix, you can send any data you like (just define a namespace and off you go), and extend existing data with anything you like. You can also go wild and define your own APIs, and room versions (i.e. dialects of the protocol) under your own namespace. Matrix provides mechanisms for backwards compatibility & fallback for clients (and servers, in future) which don't speak your dialect. However, it's abundantly clear that when doing so you are going off piste (although you're welcome to propose your extensions as a change to the main spec).
* Both protocols are open standards, maintained by non-profit foundations (https://matrix.org/foundation and https://xmpp.org/about/xmpp-standards-foundation/). Both started off being built by commercial teams (New Vector Ltd and Jabber Inc respectively) before progressively shifting to an open governance model.
Finally, the weirdest thing about this random IETF mailing list post popping up from April 2021 is that I believe the IETF chose to go with Zulip in the end: their tools team was freaked out that Matrix was openly federating and replicating history from non-IETF servers onto their instance (plus Synapse's admin UI is lacking). On the Matrix side, our solution to this will obviously be to work with the Zulip folks to get Zulip talking Matrix :)
(Disclaimer: i work on Matrix).