[HN Gopher] IETF should keep XMPP as IM standard, instead of Matrix
___________________________________________________________________
IETF should keep XMPP as IM standard, instead of Matrix
Author : zaik
Score : 64 points
Date : 2022-01-16 19:25 UTC (3 hours ago)
(HTM) web link (mailarchive.ietf.org)
(TXT) w3m dump (mailarchive.ietf.org)
| tommiegannert wrote:
| 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 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
|
| Aside from https://spec.matrix.org/unstable/client-server-
| api/#send-to-... and 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 wrote:
| 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-...), 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).
| olliej wrote:
| 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 wrote:
| _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._
| olliej wrote:
| 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.
| Macha wrote:
| 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.
| CameronNemo wrote:
| 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)?
| paulcarroty wrote:
| 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 wrote:
| > 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.
| OrvalWintermute wrote:
| 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
| Svip wrote:
| They still do. I communicate through Bitlbee/libpurple's XMPP
| client with friends on Google Hangouts (or whatever it is
| called now).
| sascha_sl wrote:
| 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.
| tannhaeuser wrote:
| > _XML is not a good serialization format_
|
| Indeed, but here we're talking about a text format for human-
| human communication, something that markup languages (SGML,
| XML) were made for.
| sascha_sl wrote:
| in my experience (working with academic data, JSON-LD), being
| aggressively semantic and adding namespaces to your format
| very rarely results in out of the box machine
| interoperability, and picking the right format out of a bunch
| being offered is always extra complexity on the side of the
| developer. but most of the time you'll likely be writing code
| specifically for one source of data.
|
| this leads to such standards having a shadow de-facto
| convention-based standard (e.g. everyone on the fediverse
| plays nice with Mastodon, despite ActivityPub allowing for
| things to be different).
|
| if you need it, just versioning your schema is imo a much
| better experience for developers
| tannhaeuser wrote:
| > _adding namespaces to your format_
|
| Granted, in the case of XMPP (but I'm no expert here) they
| might have overused namespaces with all those protocol
| extensions (XEPs) using their own NS. XML namespaces are
| one of the few additions on top of SGML and might've looked
| like a good idea at a time when many new vocabularies were
| expected, but they're controversial even among those who
| introduced them. Eg consider the following key quote from
| [1]:
|
| > _On the one hand, the pain that is caused by XML
| Namespaces seems massively out of proportion to the
| benefits that they provide. Yet, every step on the process
| that led to the current situation with XML Namespaces seems
| reasonable._
|
| [1]: https://blog.jclark.com/2010/01/xml-namespaces.html
| eat_veggies wrote:
| 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 wrote:
| 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.
| Gigachad wrote:
| I was impressed at how easy it is to work with the matrix
| protocol. While playing around I was doing it all
| interactively in bash using curl. Want to read the latest
| messages? Curl the sync url. Want to send a new message? Post
| a small json object.
|
| It's actually easier to use by hand than IRC which requires
| holding an open connection and quickly responding to pings.
|
| It becomes a little harder when end to end encryption is on
| but you just import the library they supply for almost every
| language and then e2e becomes transparent.
| stormbrew wrote:
| 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 wrote:
| > unless we get an XMPP2 that mandates certain key modern XEPs
|
| This is why https://docs.modernxmpp.org/ and compliance suits
| like https://xmpp.org/extensions/xep-0459.html exists.
| Macha wrote:
| 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 wrote:
| 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.
| jeroenhd wrote:
| That's pretty neat. Are there any compliant clients? If I
| google the XEP you linked I can't find anything but mailing
| lists and posts talking about it.
| klabb3 wrote:
| Standards need extensibility, but you can't just slap major
| extensibility framework on top of a small core and then get a
| blanked claim that competing standards must be implemented as
| extensions. A good litmus test is how useful is XMPP without
| extensions today?
|
| > it will be better for XMPP and Matrix devs to combine their
| efforts
|
| I don't like that open chat protocols have taken so long to get
| adoption either, but coercing an organizational structure seems
| like the best way to keep the status quo.
|
| Imo, good standards have been tried and proven in a "many-
| degrees-of-freedom manner" before being accepted, such as a
| major OSS project with thousands of active users, which matrix
| is doing now. Design by comittee has a terrible track record.
| Gigachad wrote:
| I think the point that FOSS enthusiasts fail to understand
| repeatedly is that once a protocol becomes so embedded and
| fractured over multiple implementations, it becomes impossible
| to change.
|
| There have been efforts to modernise irc as well but IRC still
| isn't even keeping pace, let alone catching up.
|
| I think the easiest way to handle this is to actually just drop
| legacy and start again when you reach this point. It is
| infinitely easier to build your own solution from scratch than
| it is to move a mountain and convince an existing community and
| ecosystem to do what you think is best.
|
| And matrix is proof this works. After trying it again this
| year, I think they have finally created a product which works
| really well.
| tgsovlerkhgsel wrote:
| 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.
___________________________________________________________________
(page generated 2022-01-16 23:00 UTC)