17 ms·

IETF should keep XMPP as IM standard, instead of Matrix

181 points by zaik 5y ago

shmerl 5y ago
No strong opinion. What's more important though is adoption of some interoperable standard. So far we have a huge amount of AOL/Compuserve-esque era style IM walled gardens that still refuse to interoperate. Which is ridiculous.
qwerty456127 5y ago
Who cares what IM protocol is considered the standard by IETF?
olliej 5y ago
This post is rambling nonsense. edit: As a person said I should provide detailed rationale. * It takes a large amount of text to set up a very poor and low value analogy * It doesn't say what features XMPP has that actually make it superior to matrix * It seems extrapolates from the fairly generic forward looking "Imagine a world" that matrix was started from ignorance of the existence of xmpp. A claim that is easily dismissed from any of the development documents. It has a few questionable follow on claims - basically dismissing any form of encryption as being optional based on deployment despite all current (in the last 10+ years) recognizing the encrypting messages is a core requirement of any communication system.
- CameronNemo 5y ago
  Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
  - olliej 5y ago
    I have updated the comment with the explicit problems. I still believe that the link post has near zero information as it provides no actual facts to back up any statement. All it says is "xmpp exists so it should keep existing because [hand wave]", with a dash of pseudo-biology thrown in. I feel I need to be clear here: I understand that simply saying "this is nonsense" to an arbitrary post is not reasonable, but it is also unreasonable to require a detailed teardown of posts that are nothing but nonsense. Requiring such work is a bedrock of scammers, pseudo-science, spammers, etc as it makes it harder to stop them: if every response has to be well thought out and cited eventually people give up, and the posts go uncontended, which gives them the appearance of relevance or legitimacy. This post is a nonsense article. It contains no information, it makes no actual claims beyond "we have xmpp so we should continue to have xmpp", it is far too long for the actual content, and the content that is there is largely hand waves references to a badly made and incorrect pseudo-scientific analogy. This is the kind of post that does deserve a dismissive "this is nonsense" response.
CameronNemo 5y ago
I admittedly don't know much about XMPP, but I've heard that it relies heavily on XML, which nowadays can be an offputting serialization format. Is there a XEP for using JSON(schema) (or even more dev-friendly formats like protobuf)?
- yunruse 5y ago
  XML has a few drawbacks (serialisation), but I’m not sure if it being offputting is one; you could always simply pass it through a library such as xmljson [0], if you prefer to work with what you’re familiar with. [0] https://pypi.org/project/xmljson/ https://pypi.org/project/xmljson/
- f1refly 5y ago
  Theres an XEP that allows users to write modern and not-off-putting json instead :^) https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html
paulcarroty 5y ago
One solid argument: xmpp failed as big tech (Google, Facebook) protocol and doesn't provide nothing radically better now: a ton of protocol extensions and incompatible clients. Matrix on rise: got a business with EU governments, deliver new features (spaces), with voice channels probably will enter the real rival stage with Discord/Slack.
- TonyTrapp 5y ago
  > xmpp failed as big tech (Google, Facebook) protocol Did it? They embraced it, made external XMPP clients being able to interact with their own services, and then suddenly cut them off. For all we know, they are still using XMPP internally, they just don't federate anymore.
  - Svip 5y ago
    They still do. I communicate through Bitlbee/libpurple's XMPP client with friends on Google Hangouts (or whatever it is called now).
    - hkt 5y ago
      Facebook also used xmpp in the past, it appears: https://eion.robbmob.com/blog/2009/11/04/xmpp-facebook-chat/ https://eion.robbmob.com/blog/2009/11/04/xmpp-facebook-chat/ Supposedly WhatsApp is also based on xmpp: https://en.wikipedia.org/wiki/WhatsApp https://en.wikipedia.org/wiki/WhatsApp It is a great pity that something that has created so much value for so many companies now somewhat languishes. A real shame. Not that xmpp isn't great, but it'd be so much better if the platforms that benefited from it had only contributed back more.
      - bastawhiz 5y ago
        Grindr, notably, is based on XMPP.
  - OrvalWintermute 5y ago
    I don't think xmpp failed. Cisco has products based on it, and there is a wealth of clients using it at my workplace. Many of our other partners use it. I see it as very complementary to IRC
sascha_sl 5y ago
Surprisingly short text for how long it sets up an analogy with little value. The problem with XMPP has always been that it is too extensible with too few guarantees in interoperability. You'll know what this means if you ever set up OMEMO over 3 different client implementations. It also does too much, anything from Kafkaesque (pun intended) persistent pubsub to content labels. The quality of clients is simply not good enough, so most XEPs end up in specialized variants of clients or proprietary implementations (Facebook, GTalk, EA Origin) that lean more on ejabberd's scalability than other XMPP features like federation. Also, XML is not a good serialization format, and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). JSON over websocket or HTTP are just better at reaching a wide audience of developers.
- eat_veggies 5y ago
  The reason that they needed to set up such a complicated analogy is because they needed a way to justify a hand-wavey fitness function of "extensibility/modularity" instead of the much simpler and more useful "does this thing actually survive?" Despite (or, as you argue, because of) its adaptibility, the answer to that question is empirically "no."
- zanny 5y ago
  If XMPP and Matrix were based on the same protocol stack arguments to keeping XMPP this whole time would have made sense. But they aren't. Matrix is http and json while XMPP is tcp and xml. Protocol extensions to xmpp have added http transports - but thats just wrapping non-http requests in http and making processing harder. I think a good comparison is X11 vs Wayland. X11 was retrofitted with all the functionality Wayland has natively - "why switch" is a legitimate question. But we will see in the next 20-30 years how the maintenance burden of X protocol legacy means we will see any new development using Wayland because its so much easier to do. In the same sense, chat apps will probably favor Matrix over XMPP because of the protocol maintenance burden - even when drop in libraries exist that implement XMPP, the inherent complexity makes them buggier, slower, and requires a lot of developer nuance to get right and its all due to legacy cruft you have to accommodate on an old standard. Its also like how more modern kernels stopped trying to be Unix compatible. Trying to meet the POSIX standard in the 21st century is kinda a waste of effort when a lot of it is unnecessary. The model is sound, its just adhering strictly to the eccentricities of it is just unnecessary headache.
stormbrew 5y ago
To me this is the lynchpin: > This is the very situation where matrix devs should have made use of the properties of XMPP to improve it. Even the outstanding feature (I admit. its a fantastic idea) of matrix, decentralized conversation store, could have been implemented in XMPP as an XEP. Imagine the time and effort spent on improving XMPP, instead of reinventing wheels in matrix. We could have had a neat ubiquitous IM platform. The approach XMPP took may have made sense when it was created, and it definitely had a lot of success early on at creating a truly federated IM network, but a lot of that evaporated when people and companies started needing more from the system than XMPP could guarantee. XMPP + a bag of XEPs isn't a "neat ubuquitous IM platform" unless we get an XMPP2 that mandates certain key modern XEPs. It's just a big giant mess, the same one it's been for a long time. Maybe that's where Matrix should have started, I dunno. But they are where they are and the reality is that it's not up to the IETF to dictate how things should evolve. If Matrix supplants XMPP as a dominant open IM federation, and the people behind it want it to be standardized, all the "but XMPP did it first" in the world shouldn't prevent that.
- zaik 5y ago
  > unless we get an XMPP2 that mandates certain key modern XEPs This is why https://docs.modernxmpp.org/ https://docs.modernxmpp.org/ and compliance suits like https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html exists.
  - Macha 5y ago
    So is there a list of "Modern XMPP" compliant clients, server software and hosts that I can compare the experience of to the Matrix ecosystem? I was a pretty big user of XMPP with Pidgin on first GTalk and then later DDG's server back in the day, because that's certainly not comparable. I'd really like an open chat solution to succeed, but from where I sit "Can I convince any of my friend groups to move from discord to this?", Matrix is substantially in the lead.
    - zamadatix 5y ago
      No, this discussion isn't a comparison of implementations it's a question/discussion of why "the latest implementation" is tied to a new extensible protocol instead of a new baseline of the existing extensible protocol. There may well be reasons but "the first implementation was on the new protocol" explains the current state not how things got there.
Macha 5y ago
Has IETF any policy about not having competing standards? I mean, if XMPP is an IETF standard and IRC already existed, surely they already have two. See also IMAP, JMAP and POP; several routing protocols; TFTP, FTP and SFTP.
tommiegannert 5y ago
Summaries, and my counter-arguments as someone who just replaced XMPP with Matrix, and attempting contributions to Matrix code: > [1] EVOLUTION AND NATURAL SELECTION: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect and a biology analogy taken a bit too far. Extensibility and modularity are important. Extensibility allows adding features, and modularity allows removing features. The last part sounds reasonable. The first part misses that nature is constantly creating new variations that try to become dominant. The Lindy effect suggests that older things stick around. But in nature, they don't stick around for the sake of age. They stick around because nothing better has out-competed them yet. This analogy seems moot to me. > [2] IGNORANCE: I think this kind of trend "Protocol ABC doesn't have this XYZ feature, so let me start a protocol from scratch" should be discouraged. Yes, but this is a very shallow argument. The rest of the world has advanced in terms of protocol infrastructure. We're on HTTP/2, and playing with HTTP/3 [1]. IPv6 might actually happen in my lifetime. Meanwhile, XMPP is one-long-XML-document-over-TCP and requires custom tooling for everything. IM protocols don't existing in a vacuum, and should be re-evaluated based on global knowledge, not just IM protocol history. > [3] FLEXIBLE DEPLOYMENT: IM platforms should be able to be deployed as minimal as possible or as feature as possible. Certain features should be able to be optionally enabled or disabled, based on the needs of the deployer. If an activist collective doesn't want to store any messages on server for privacy purposes, it can be done by dropping the XEP responsible for archiving. Matrix cannot do this. For sure, modularity helps flexibility. Matrix is modular and uses token strings in most places where extensions could occur. https://spec.matrix.org/unstable/client-server-api/#modules https://spec.matrix.org/unstable/client-server-api/#modules Aside from https://spec.matrix.org/unstable/client-server-api/#send-to-device-messaging https://spec.matrix.org/unstable/client-server-api/#send-to-... and https://spec.matrix.org/unstable/client-server-api/#end-to-end-encryption https://spec.matrix.org/unstable/client-server-api/#end-to-e... solving this rather strange concern about archiving... The example that you can't drop archiving is silly in the context of flexible deployment. Why does it matter whether archiving is an extension or just a server setting? Someone had to consider the configurability either way. However, Matrix is essentially an append-only event store, so in this particular example, yes, you wouldn't be able to disable storing. It's fundamental to Matrix. You can of course prune historical events, but that's not the intent. I feel the bigger question "should an IM protocol be based on distributed state replication?" deserves a better argument than "it's not implemented as an extension." It provides other benefits, like read markers and complete ordering of e.g. ACL changes in rooms. --- This seems to be many words, but not much insight into the concrete merits of either of XMPP or Matrix. [1] I'll leave chat protocols on the block chains out of this.
Arathorn 5y ago
The whole "why didn't Matrix just build on XMPP?" thing is incredibly tedious - you'd hope people would have got over it by now. 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-end-encryption-by-default-is-here 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 https://matrix.org/foundation and https://xmpp.org/about/xmpp-standards-foundation/ 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).
tgsovlerkhgsel 5y ago
I'd argue XMPP has died long ago, at least for the purpose of the "Anything in this world that has survived for a long-time, had to be fit to withstand selective pressures." argument. Of course it isn't completely dead, just like some enthusiasts still use about every imaginable historical computing platform, but for practical purposes, I think most public communities have moved, usually either to Matrix or closed platforms like Discord or Telegram.
egberts1 5y ago
XML? Too much serialization overhead. JSON? Still too much serialization. BSON, there ye go.
blooalien 5y ago
I'm not quite understanding the "instead of Matrix" part… Why not both? Is the IETF unable to support more than a single standard for a particular purpose/task?
mnot 5y ago
Just for context -- there's a discussion in the IETF about what collaboration tools it should use (e.g., for working group meetings and general discussion) in addition to e-mail. A few different options have been trialed, including Zulip and Matrix. This is NOT about the IETF recommending one chat / collaboration protocol over another, or standardising Matrix.
eschaton 5y ago
Honestly neither websockets over HTTP nor the underlying protocols used by XMPP are particularly good. They should be designed more like IMAP; at CMU during the first significant IETF instant messaging effort, Rob Earhart distilled the lessons of IMAP into an “Access Protocol” Internet draft that makes for a better substrate for pretty much any Internet protocol: https://datatracker.ietf.org/doc/draft-earhart-ap-spec/ https://datatracker.ietf.org/doc/draft-earhart-ap-spec/ A lot of the reason the IETF process around IM was so lengthy and led to so much cruft and weirdness is that there were telco folks on the lists who insisted that only small UDP packets would ever get through telco networks and TCP was an absolute non-starter, and kept trying to center the discussion around their current data networks rather than even the planned 2G and 3G networks. Also, just like email, an instant message protocol should be connection-based (TCP), provide good response time for plain text messaging over a 9600bps or slower link, and only require a page or two of C code to parse without heavy use of the standard library.
- chrismorgan 5y ago
  In a vacuum, something like that Access Protocol may be good, but we’re not in a vacuum. The web has won, and basing things on top of web specs conveys significant advantages: the general tooling for HTTP/XML/JSON is much better than the tooling for any specific-purpose binary or text protocol that I know of, so you can get started building stuff much more quickly, with better understood and handled failure modes, and better tools for debugging when anything goes wrong; and the large fraction of the world’s software that runs inside a web browser can also take advantage of this without needing some kind of non-standard server proxy. Most of the time I would say these advantages significantly outweigh the disadvantages of inefficiency. There are reasons JMAP was designed to sit on top of HTTP and JSON. It makes life much easier.
- octoberfranklin 5y ago
  > only small UDP packets There's something to be said for that here, however. When was the last time you typed out a chat/IRC message longer than 512 bytes? That's the minimum MTU on the Internet; packets below that size can ignore fragmentation and the retransmission-amplification that comes with it. Here's a beautifully elegant chat protocol that uses only UDP: http://www.loper-os.org/?p=3992 http://www.loper-os.org/?p=3992 It also uses only symmetric crypto, for "that's a feature not a bug" reasons; among them: it forces its users to forge decentralized WoTs instead of relying on big centralized platforms to authenticate their own friends to them. > A lot of the reason the IETF process ... led to so much cruft and weirdness is that there were telco folks That has been a major problem for a long time now.
frabbit 5y ago
Anything in this world that has survived for a long-time, had to be fit to withstand selective pressures. So look at what existed for long time, that's probably has properties to adapt well.". This seems confused and and misguided. All it means is that it survived the selective pressures to which it was historically exposed. It doesn't mean they were the best of all possible species, just the best (given the environment) compared to the others at the time, solely at the task of making more copies of themselves.
- Sebb767 5y ago
  > It doesn't mean they were the best of all possible species, just the best (given the environment) compared to the others at the time, solely at the task of making more copies of themselves. There's a very long list of failed 'perfect' standards. "Working in the current environment and recruiting new users" looks like a very reasonable bar for a standard to clear.
mrlonglong 5y ago
What's wrong with IRC? Still works for me
octoberfranklin 5y ago
Frankly this is a moot point until there is more than one complete implementation of the Matrix "protocol", including particularly the critical "homeserver" part. Until then it really isn't standardized; the protocol is, effectively, "do whatever the one and only implementation does".
rvz 5y ago
says who?
INTPenis 5y ago
If the choice is between xmpp and matrix it's a no-brainer to be honest. I was a matrix node operator for a while, because I love operating all sorts of decentralized stuff for people in my free time. In short, my findings were that the server implementations are not ready for critical production, like the IETF for example. The choice of server implementation is super important because it locks you into a certain SQL structure and possibly even a certain password hashing. So back then I obviously went with synapse because the others were not even nearly ready. But at the same time matrix.org is struggling under a new wave of sign-ups. And they're still struggling. I still see messages on boards and IRC like "why is my client just hanging when I join a room", likely because people in that room are federating with Matrix.org and it's super slow. So that wasn't a good impression of synapse right off the bat. It being the first reference implementation in Python I figured it just wasn't good at scaling. I would need more k8s resources to scale it than I would an implementation in Rust or Golang. So now I'm waiting for dendrite or one of the other ones to become fully featured with group messages, encryption and all that until I re-launch my matrix instance. I also won't launch it without a proper implementation for account approval, or invites, either one I make myself or someone else publishes one before that. AND even if one of the faster implementations is ready, you still have to take into account the client app support for platforms like iOS and Android.
- luplex 5y ago
  I agree. Matrix isn't quite ready for its prime time, but it's getting there. Synapse is getting more efficient with every update, and the spec is doing so as well. For example, they recently released the new sync API, which makes joining a room almost instant. I'm really looking forward to low-bandwidth Matrix as well, which is going to improve performance by a lot. Client compatibility seems pretty good overall, with Element and Fluffychat available to almost everyone. In my eyes, the biggest weak point for Matrix as an IM protocol is that there's no business model for server providers.
  - olah_1 5y ago
    > the biggest weak point for Matrix as an IM protocol is that there's no business model for server providers. This wouldnt be as bad if we had account portability. I just want my account to be a key. i’m sick of being tied to servers with whack domain names.
wusspuss 5y ago
XMPP is extensible huh? Extend it to not torture implementation developers with xml. You can't. That's the law of software. Good components tend to be easily replaceable, bad components do not. Thus overtime as software evolves it ends up made of mostly or only bad components.

181 points by zaik 5y ago

No strong opinion. What's more important though is adoption of some interoperable standard. So far we have a huge amount of AOL/Compuserve-esque era style IM walled gardens that still refuse to interoperate. Which is ridiculous.

qwerty456127 5y ago

Who cares what IM protocol is considered the standard by IETF?

olliej 5y ago

This post is rambling nonsense. edit: As a person said I should provide detailed rationale. * It takes a large amount of text to set up a very poor and low value analogy * It doesn't say what features XMPP has that actually make it superior to matrix * It seems extrapolates from the fairly generic forward looking "Imagine a world" that matrix was started from ignorance of the existence of xmpp. A claim that is easily dismissed from any of the development documents. It has a few questionable follow on claims - basically dismissing any form of encryption as being optional based on deployment despite all current (in the last 10+ years) recognizing the encrypting messages is a core requirement of any communication system.

CameronNemo 5y ago
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
- olliej 5y ago
  I have updated the comment with the explicit problems. I still believe that the link post has near zero information as it provides no actual facts to back up any statement. All it says is "xmpp exists so it should keep existing because [hand wave]", with a dash of pseudo-biology thrown in. I feel I need to be clear here: I understand that simply saying "this is nonsense" to an arbitrary post is not reasonable, but it is also unreasonable to require a detailed teardown of posts that are nothing but nonsense. Requiring such work is a bedrock of scammers, pseudo-science, spammers, etc as it makes it harder to stop them: if every response has to be well thought out and cited eventually people give up, and the posts go uncontended, which gives them the appearance of relevance or legitimacy. This post is a nonsense article. It contains no information, it makes no actual claims beyond "we have xmpp so we should continue to have xmpp", it is far too long for the actual content, and the content that is there is largely hand waves references to a badly made and incorrect pseudo-scientific analogy. This is the kind of post that does deserve a dismissive "this is nonsense" response.

CameronNemo 5y ago

I admittedly don't know much about XMPP, but I've heard that it relies heavily on XML, which nowadays can be an offputting serialization format. Is there a XEP for using JSON(schema) (or even more dev-friendly formats like protobuf)?

yunruse 5y ago
XML has a few drawbacks (serialisation), but I’m not sure if it being offputting is one; you could always simply pass it through a library such as xmljson [0], if you prefer to work with what you’re familiar with. [0] https://pypi.org/project/xmljson/ https://pypi.org/project/xmljson/
f1refly 5y ago
Theres an XEP that allows users to write modern and not-off-putting json instead :^) https://xmpp.org/extensions/xep-0295.html https://xmpp.org/extensions/xep-0295.html

paulcarroty 5y ago

One solid argument: xmpp failed as big tech (Google, Facebook) protocol and doesn't provide nothing radically better now: a ton of protocol extensions and incompatible clients. Matrix on rise: got a business with EU governments, deliver new features (spaces), with voice channels probably will enter the real rival stage with Discord/Slack.

TonyTrapp 5y ago
> xmpp failed as big tech (Google, Facebook) protocol Did it? They embraced it, made external XMPP clients being able to interact with their own services, and then suddenly cut them off. For all we know, they are still using XMPP internally, they just don't federate anymore.
- Svip 5y ago
  They still do. I communicate through Bitlbee/libpurple's XMPP client with friends on Google Hangouts (or whatever it is called now).
  - hkt 5y ago
    Facebook also used xmpp in the past, it appears: https://eion.robbmob.com/blog/2009/11/04/xmpp-facebook-chat/ https://eion.robbmob.com/blog/2009/11/04/xmpp-facebook-chat/ Supposedly WhatsApp is also based on xmpp: https://en.wikipedia.org/wiki/WhatsApp https://en.wikipedia.org/wiki/WhatsApp It is a great pity that something that has created so much value for so many companies now somewhat languishes. A real shame. Not that xmpp isn't great, but it'd be so much better if the platforms that benefited from it had only contributed back more.
    - bastawhiz 5y ago
      Grindr, notably, is based on XMPP.
- OrvalWintermute 5y ago
  I don't think xmpp failed. Cisco has products based on it, and there is a wealth of clients using it at my workplace. Many of our other partners use it. I see it as very complementary to IRC

sascha_sl 5y ago

Surprisingly short text for how long it sets up an analogy with little value. The problem with XMPP has always been that it is too extensible with too few guarantees in interoperability. You'll know what this means if you ever set up OMEMO over 3 different client implementations. It also does too much, anything from Kafkaesque (pun intended) persistent pubsub to content labels. The quality of clients is simply not good enough, so most XEPs end up in specialized variants of clients or proprietary implementations (Facebook, GTalk, EA Origin) that lean more on ejabberd's scalability than other XMPP features like federation. Also, XML is not a good serialization format, and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS). JSON over websocket or HTTP are just better at reaching a wide audience of developers.

eat_veggies 5y ago
The reason that they needed to set up such a complicated analogy is because they needed a way to justify a hand-wavey fitness function of "extensibility/modularity" instead of the much simpler and more useful "does this thing actually survive?" Despite (or, as you argue, because of) its adaptibility, the answer to that question is empirically "no."
zanny 5y ago
If XMPP and Matrix were based on the same protocol stack arguments to keeping XMPP this whole time would have made sense. But they aren't. Matrix is http and json while XMPP is tcp and xml. Protocol extensions to xmpp have added http transports - but thats just wrapping non-http requests in http and making processing harder. I think a good comparison is X11 vs Wayland. X11 was retrofitted with all the functionality Wayland has natively - "why switch" is a legitimate question. But we will see in the next 20-30 years how the maintenance burden of X protocol legacy means we will see any new development using Wayland because its so much easier to do. In the same sense, chat apps will probably favor Matrix over XMPP because of the protocol maintenance burden - even when drop in libraries exist that implement XMPP, the inherent complexity makes them buggier, slower, and requires a lot of developer nuance to get right and its all due to legacy cruft you have to accommodate on an old standard. Its also like how more modern kernels stopped trying to be Unix compatible. Trying to meet the POSIX standard in the 21st century is kinda a waste of effort when a lot of it is unnecessary. The model is sound, its just adhering strictly to the eccentricities of it is just unnecessary headache.

stormbrew 5y ago

To me this is the lynchpin: > This is the very situation where matrix devs should have made use of the properties of XMPP to improve it. Even the outstanding feature (I admit. its a fantastic idea) of matrix, decentralized conversation store, could have been implemented in XMPP as an XEP. Imagine the time and effort spent on improving XMPP, instead of reinventing wheels in matrix. We could have had a neat ubiquitous IM platform. The approach XMPP took may have made sense when it was created, and it definitely had a lot of success early on at creating a truly federated IM network, but a lot of that evaporated when people and companies started needing more from the system than XMPP could guarantee. XMPP + a bag of XEPs isn't a "neat ubuquitous IM platform" unless we get an XMPP2 that mandates certain key modern XEPs. It's just a big giant mess, the same one it's been for a long time. Maybe that's where Matrix should have started, I dunno. But they are where they are and the reality is that it's not up to the IETF to dictate how things should evolve. If Matrix supplants XMPP as a dominant open IM federation, and the people behind it want it to be standardized, all the "but XMPP did it first" in the world shouldn't prevent that.

zaik 5y ago
> unless we get an XMPP2 that mandates certain key modern XEPs This is why https://docs.modernxmpp.org/ https://docs.modernxmpp.org/ and compliance suits like https://xmpp.org/extensions/xep-0459.html https://xmpp.org/extensions/xep-0459.html exists.
- Macha 5y ago
  So is there a list of "Modern XMPP" compliant clients, server software and hosts that I can compare the experience of to the Matrix ecosystem? I was a pretty big user of XMPP with Pidgin on first GTalk and then later DDG's server back in the day, because that's certainly not comparable. I'd really like an open chat solution to succeed, but from where I sit "Can I convince any of my friend groups to move from discord to this?", Matrix is substantially in the lead.
  - zamadatix 5y ago
    No, this discussion isn't a comparison of implementations it's a question/discussion of why "the latest implementation" is tied to a new extensible protocol instead of a new baseline of the existing extensible protocol. There may well be reasons but "the first implementation was on the new protocol" explains the current state not how things got there.

Macha 5y ago

Has IETF any policy about not having competing standards? I mean, if XMPP is an IETF standard and IRC already existed, surely they already have two. See also IMAP, JMAP and POP; several routing protocols; TFTP, FTP and SFTP.

tommiegannert 5y ago

Summaries, and my counter-arguments as someone who just replaced XMPP with Matrix, and attempting contributions to Matrix code: > [1] EVOLUTION AND NATURAL SELECTION: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect and a biology analogy taken a bit too far. Extensibility and modularity are important. Extensibility allows adding features, and modularity allows removing features. The last part sounds reasonable. The first part misses that nature is constantly creating new variations that try to become dominant. The Lindy effect suggests that older things stick around. But in nature, they don't stick around for the sake of age. They stick around because nothing better has out-competed them yet. This analogy seems moot to me. > [2] IGNORANCE: I think this kind of trend "Protocol ABC doesn't have this XYZ feature, so let me start a protocol from scratch" should be discouraged. Yes, but this is a very shallow argument. The rest of the world has advanced in terms of protocol infrastructure. We're on HTTP/2, and playing with HTTP/3 [1]. IPv6 might actually happen in my lifetime. Meanwhile, XMPP is one-long-XML-document-over-TCP and requires custom tooling for everything. IM protocols don't existing in a vacuum, and should be re-evaluated based on global knowledge, not just IM protocol history. > [3] FLEXIBLE DEPLOYMENT: IM platforms should be able to be deployed as minimal as possible or as feature as possible. Certain features should be able to be optionally enabled or disabled, based on the needs of the deployer. If an activist collective doesn't want to store any messages on server for privacy purposes, it can be done by dropping the XEP responsible for archiving. Matrix cannot do this. For sure, modularity helps flexibility. Matrix is modular and uses token strings in most places where extensions could occur. https://spec.matrix.org/unstable/client-server-api/#modules https://spec.matrix.org/unstable/client-server-api/#modules Aside from https://spec.matrix.org/unstable/client-server-api/#send-to-device-messaging https://spec.matrix.org/unstable/client-server-api/#send-to-... and https://spec.matrix.org/unstable/client-server-api/#end-to-end-encryption https://spec.matrix.org/unstable/client-server-api/#end-to-e... solving this rather strange concern about archiving... The example that you can't drop archiving is silly in the context of flexible deployment. Why does it matter whether archiving is an extension or just a server setting? Someone had to consider the configurability either way. However, Matrix is essentially an append-only event store, so in this particular example, yes, you wouldn't be able to disable storing. It's fundamental to Matrix. You can of course prune historical events, but that's not the intent. I feel the bigger question "should an IM protocol be based on distributed state replication?" deserves a better argument than "it's not implemented as an extension." It provides other benefits, like read markers and complete ordering of e.g. ACL changes in rooms. --- This seems to be many words, but not much insight into the concrete merits of either of XMPP or Matrix. [1] I'll leave chat protocols on the block chains out of this.

Arathorn 5y ago

The whole "why didn't Matrix just build on XMPP?" thing is incredibly tedious - you'd hope people would have got over it by now. 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-end-encryption-by-default-is-here 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 https://matrix.org/foundation and https://xmpp.org/about/xmpp-standards-foundation/ 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).

tgsovlerkhgsel 5y ago

I'd argue XMPP has died long ago, at least for the purpose of the "Anything in this world that has survived for a long-time, had to be fit to withstand selective pressures." argument. Of course it isn't completely dead, just like some enthusiasts still use about every imaginable historical computing platform, but for practical purposes, I think most public communities have moved, usually either to Matrix or closed platforms like Discord or Telegram.

egberts1 5y ago

XML? Too much serialization overhead. JSON? Still too much serialization. BSON, there ye go.

blooalien 5y ago

I'm not quite understanding the "instead of Matrix" part… Why not both? Is the IETF unable to support more than a single standard for a particular purpose/task?

mnot 5y ago

Just for context -- there's a discussion in the IETF about what collaboration tools it should use (e.g., for working group meetings and general discussion) in addition to e-mail. A few different options have been trialed, including Zulip and Matrix. This is NOT about the IETF recommending one chat / collaboration protocol over another, or standardising Matrix.

eschaton 5y ago

Honestly neither websockets over HTTP nor the underlying protocols used by XMPP are particularly good. They should be designed more like IMAP; at CMU during the first significant IETF instant messaging effort, Rob Earhart distilled the lessons of IMAP into an “Access Protocol” Internet draft that makes for a better substrate for pretty much any Internet protocol: https://datatracker.ietf.org/doc/draft-earhart-ap-spec/ https://datatracker.ietf.org/doc/draft-earhart-ap-spec/ A lot of the reason the IETF process around IM was so lengthy and led to so much cruft and weirdness is that there were telco folks on the lists who insisted that only small UDP packets would ever get through telco networks and TCP was an absolute non-starter, and kept trying to center the discussion around their current data networks rather than even the planned 2G and 3G networks. Also, just like email, an instant message protocol should be connection-based (TCP), provide good response time for plain text messaging over a 9600bps or slower link, and only require a page or two of C code to parse without heavy use of the standard library.

chrismorgan 5y ago
In a vacuum, something like that Access Protocol may be good, but we’re not in a vacuum. The web has won, and basing things on top of web specs conveys significant advantages: the general tooling for HTTP/XML/JSON is much better than the tooling for any specific-purpose binary or text protocol that I know of, so you can get started building stuff much more quickly, with better understood and handled failure modes, and better tools for debugging when anything goes wrong; and the large fraction of the world’s software that runs inside a web browser can also take advantage of this without needing some kind of non-standard server proxy. Most of the time I would say these advantages significantly outweigh the disadvantages of inefficiency. There are reasons JMAP was designed to sit on top of HTTP and JSON. It makes life much easier.
octoberfranklin 5y ago
> only small UDP packets There's something to be said for that here, however. When was the last time you typed out a chat/IRC message longer than 512 bytes? That's the minimum MTU on the Internet; packets below that size can ignore fragmentation and the retransmission-amplification that comes with it. Here's a beautifully elegant chat protocol that uses only UDP: http://www.loper-os.org/?p=3992 http://www.loper-os.org/?p=3992 It also uses only symmetric crypto, for "that's a feature not a bug" reasons; among them: it forces its users to forge decentralized WoTs instead of relying on big centralized platforms to authenticate their own friends to them. > A lot of the reason the IETF process ... led to so much cruft and weirdness is that there were telco folks That has been a major problem for a long time now.

frabbit 5y ago

Anything in this world that has survived for a long-time, had to be fit to withstand selective pressures. So look at what existed for long time, that's probably has properties to adapt well.". This seems confused and and misguided. All it means is that it survived the selective pressures to which it was historically exposed. It doesn't mean they were the best of all possible species, just the best (given the environment) compared to the others at the time, solely at the task of making more copies of themselves.

Sebb767 5y ago
> It doesn't mean they were the best of all possible species, just the best (given the environment) compared to the others at the time, solely at the task of making more copies of themselves. There's a very long list of failed 'perfect' standards. "Working in the current environment and recruiting new users" looks like a very reasonable bar for a standard to clear.

mrlonglong 5y ago

What's wrong with IRC? Still works for me

octoberfranklin 5y ago

Frankly this is a moot point until there is more than one complete implementation of the Matrix "protocol", including particularly the critical "homeserver" part. Until then it really isn't standardized; the protocol is, effectively, "do whatever the one and only implementation does".

rvz 5y ago

says who?

INTPenis 5y ago

If the choice is between xmpp and matrix it's a no-brainer to be honest. I was a matrix node operator for a while, because I love operating all sorts of decentralized stuff for people in my free time. In short, my findings were that the server implementations are not ready for critical production, like the IETF for example. The choice of server implementation is super important because it locks you into a certain SQL structure and possibly even a certain password hashing. So back then I obviously went with synapse because the others were not even nearly ready. But at the same time matrix.org is struggling under a new wave of sign-ups. And they're still struggling. I still see messages on boards and IRC like "why is my client just hanging when I join a room", likely because people in that room are federating with Matrix.org and it's super slow. So that wasn't a good impression of synapse right off the bat. It being the first reference implementation in Python I figured it just wasn't good at scaling. I would need more k8s resources to scale it than I would an implementation in Rust or Golang. So now I'm waiting for dendrite or one of the other ones to become fully featured with group messages, encryption and all that until I re-launch my matrix instance. I also won't launch it without a proper implementation for account approval, or invites, either one I make myself or someone else publishes one before that. AND even if one of the faster implementations is ready, you still have to take into account the client app support for platforms like iOS and Android.

luplex 5y ago
I agree. Matrix isn't quite ready for its prime time, but it's getting there. Synapse is getting more efficient with every update, and the spec is doing so as well. For example, they recently released the new sync API, which makes joining a room almost instant. I'm really looking forward to low-bandwidth Matrix as well, which is going to improve performance by a lot. Client compatibility seems pretty good overall, with Element and Fluffychat available to almost everyone. In my eyes, the biggest weak point for Matrix as an IM protocol is that there's no business model for server providers.
- olah_1 5y ago
  > the biggest weak point for Matrix as an IM protocol is that there's no business model for server providers. This wouldnt be as bad if we had account portability. I just want my account to be a key. i’m sick of being tied to servers with whack domain names.

wusspuss 5y ago

XMPP is extensible huh? Extend it to not torture implementation developers with xml. You can't. That's the law of software. Good components tend to be easily replaceable, bad components do not. Thus overtime as software evolves it ends up made of mostly or only bad components.