IETF should keep XMPP as IM standard, instead of Matrix

https://mailarchive.ietf.org/arch/msg/tools-discuss/Cj7n-7HwsN8xBzXCjD1pjD1j9Cg/

by zaik • 5 years ago

181 177 5 years ago

mailarchive.ietf.org

olliej2• 5 years 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.

CameronNemo2• 5 years ago

Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

olliej2• 5 years 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.

CameronNemo2• 5 years 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• 5 years 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/

f1refly• 5 years ago

Theres an XEP that allows users to write modern and not-off-putting json instead :^)

https://xmpp.org/extensions/xep-0295.html

paulcarroty• 5 years 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• 5 years 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• 5 years ago

They still do. I communicate through Bitlbee/libpurple's XMPP client with friends on Google Hangouts (or whatever it is called now).

OrvalWintermute• 5 years 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

lmm12• 5 years ago

Like many extension-oriented protocols, XMPP works for internal use where the same organisation (or two closely cooperating organisations) control both ends, but doesn't work for communication between two loosely connected or unrelated parties.

sascha_sl3• 5 years 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.

zanny• 5 years 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.

Gigachad5• 5 years ago

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.

eat_veggies• 5 years 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."

tannhaeuser2• 5 years ago

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_sl3• 5 years ago

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

salawat• 5 years ago

XML is not a good serialization format

I have never seen a good justification for this attestation that isn't some variation of "you're not accommodating the optimization I want to do that is orthogonal to rendering this binary representation into a persistent representation suitable for long term storage or transmission to another system".

Even the great XML/JSON flamewar ended up with the same exact ecosystem of tools being implemented for both encoding schemes. XPATH/jq JSON schema, XML Schemas, etc...

It's all encoding. There isn't good or bad; there's different, and works with what I've got with no additional work. That's it.

jcranmer• 5 years ago

One of the particular issues I recall hearing someone talk about with XMPP is that it uses XML in a way that makes it hard to use existing libraries--I believe XMPP basically relies on an unclosed XML document that keeps getting appended to, so you need to have strong partial parsing guarantees that's unusual for XML formats.

Sebb7674• 5 years ago

I've posted it in another subthread already, but XML, with its nesting and attributes, doesn't map particularly well to a specific programming construct. Also, you can represent an object hierarchy in a lot of ways and it's very verbose for even the smallest stuff.

JSON, on the other hand, is dead simple: You have your list/array, dict/object and four value types. Representing JSON in your favorite language is straight-foward and how the serialized version of a hierarchy looks is immediately obvious in nearly all cases.

defanor2• 5 years ago

too extensible

I don't see how it's a problem, except for:

with too few guarantees in interoperability

...Which indeed makes life harder. As mentioned elsewhere in the discussion, there are compliance suites, and capabilities and feature discovery, but the clients are indeed quite diverse, and sometimes it's hard to know what to expect from them.

XML is not a good serialization format

I personally find it more suitable than JSON for many purposes, including extensible IM, for a couple of reasons: namespaces help to avoid conflicts, while the data model itself is more convenient for general data encoding since it's straightforward to encode sum types in XML (where a tag corresponds to a constructor), unlike in JSON (where there's a few ways to achieve it, though with JSON-over-HTTP that part is usually only done on the top level and goes into HTTP query). Maybe I'd prefer s-expressions to XML for an IM, but not JSON.

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

I wouldn't call that one "exotic": STARTTLS is used by a few other common protocols, and allows for opportunistic TLS; easily usable with common libraries (OpenSSL, GnuTLS) too. There's XEP-0368: SRV records for XMPP over TLS [1] for direct TLS connections though.

[1] https://xmpp.org/extensions/xep-0368.html

azalemeth• 5 years ago

I've never understood why XML gets so much hate outside of the context of the browser. Yes, it's verbose but fully featured parsers are everywhere and it seems far easier to include a random (base-64'd) binary blob in place if required as opposed to JSON. This is an area I know little about -- I'd love someone more knowledgeable to educate me.

djur4• 5 years ago

Unbounded extensibility is a great way to get adoption of a standard, in the sense that a lot of products will say "Fully $standard Compatible!" in their marketing materials. It is a bad way to ensure that the standard actually means anything outside the marketing materials.

jeroenhd3• 5 years ago

I don't get the XML hate, to be honest. Everyone who drops XML to make it simpler to use eventually re-invents most of XML.

I find typing YAML to be much better than typing XML, but when it comes to serialization, I honestly don't see why JSON is that much better. To solve interoperability, there are three or four JSON schema standards and sometimes extensive written documentation just to explain the types of fields and when they can occur.

Now I need to find out which type of JSON an application uses (does it always use UTF8 or does it break the standard? Which version of the JSON Schema does it use? Is it using a schema at all? What happens when "$ref" appears in the content body? How should I deal with duplicate keys?) and how to properly encode it. It's the quick & dirty way to serialize data, and that's great for messing around with prototypes and getting started quick, but terrible for business critical applications and public-facing APIs.

All serialization formats are stupid and messy in some way but I think XML gets a bad rep because of the defaults many parsing libraries picked (and the vulnerabilities they introduced). Protobuf and friends are probably a much better serialization system for chat messages.

I don't see why developers fear XML so much. I think it has to do with the fact that everything is built by web developers now. Sockets have been replaced by sockets and concise protocols have been replaced by messy HTTP requests. I wonder how long it'll be before ISPs start blocking any traffic not directed towards port 80/443.

tormeh2• 5 years ago

JSON seems to have better parsers than XML, and XML is more verbose. XML has comments though. That said, I think they're more or less equivalent. I hate YAML, though. Awful awful language. Surprisingly complex, and whitespace sensitivity in a language that's templated all the time? Must be the work of the devil. JSON > XML >>>> YAML, IMO.

gen220• 5 years ago

I think XML gets a bad rep for a similar reason that CSV gets a bad rep.

i.e. there is a wide variance of what “passes” for XML, and two systems that profess to “speak” XML often speak mutually incomprehensible dialects.

I think each of your valid complaints about JSON extend to XML, for example. Totally agreed that XML gets an especially bad rep because most xml parsing/generating libraries in popular programming languages are frustrating.

canadaduane• 5 years ago

I liked this summary: XML is almost always misused [1]

The gist is that XML is best used for markup, because it inherits assumptions from the "document" metaphor that are not needed and are sometimes unhelpful for data interchange. An example of this is hashmaps & sets--they intentionally leave "order" or "sequence" out of their representation, but documents as a form of data interchange force you to keep thinking about it.

[1] https://www.devever.net/~hl/xml

jayd16• 5 years ago

re-invents most of XML.

That's fine though. Only a few bits of XML make the format very cumbersome to support.

cbsmith2• 5 years ago

"All human readable serialization formats are stupid and messy in some way".

Fixed that for you.

There's plenty of simple binary serialization formats that, while not perfect, don't generally qualify as stupid or messy.

inopinatus• 5 years ago

XML is also superfluous by this standard, since by induction on the principle of "unnecessary reimplementation", we could be exchanging data via S-expressions.

stormbrew6• 5 years ago

When do you put something in an attribute and when do you give it its own tag? What if semantically it belongs in an attribute but the kind of complicated parsing rules make putting it there cumbersome? Should you use <![CDATA[]]> or base64 to encode non-xml data? If you use CDATA what if the data has a ]]>? If you use tags for hierarchical information, what do you do if there happens to be some random non-whitespace/comment data between the tags as if it was html?

I don't really like interacting with json as a human user (mostly because restricting trailing commas and comments are both utterly awful design choices), but I'd take it a hundred times over the enormous ball of complexity and decision paralysis that xml imposes on you. There's just too much there there.

lmm12• 5 years ago

Now I need to find out which type of JSON an application uses (does it always use UTF8 or does it break the standard? Which version of the JSON Schema does it use? Is it using a schema at all? What happens when "$ref" appears in the content body? How should I deal with duplicate keys?) and how to properly encode it. It's the quick & dirty way to serialize data, and that's great for messing around with prototypes and getting started quick, but terrible for business critical applications and public-facing APIs.

I've never known any of XML's features to help with actually solving a business problem. Oh great, your documents have a mandatory schema; what benefit does that actually give you? It doesn't mean you can skip doing logical validation of a request/response post-deserialization (a schema can enforce that an id is an integer, but not that it's an id that actually exists in your database). In theory it might make it easier to complain about bugs where the real system doesn't match the documentation, but in practice it's more likely to be considered an error in the schema than a bug in the system. As far as I can tell all that using a schema actually does is means that you'll occasionally reject a document that you could have processed, or (even better) refuse to load the document because the schema's website is down.

Similarly with namespaces: the only impact I've ever known XML namespaces to have is to frustrate users who can't understand why their XPaths aren't matching until they configure all their namespaces. I know in theory there are cases where one XML document embedded in another might mean that an XPath would match something it shouldn't, but I've literally never seen that happen in real life, whereas having everything silently not match until someone configures namespaces happens all the time.

Similarly with custom entities, the only thing I've seen them used for is DOSes.

There's also a bunch of other issues: standard XML Schema is awful (RelaxNG is better, but you can't use it because it's not the official schema format), the format is almost-but-not-quite whitespace-insensitive which gives you the worst of both worlds (and similarly for text encodings), and XML is deeply associated with verbose overengineering because that's the main thing it's historically been used for. But even putting those aside, it really is as bad as it's made out to be.

Protobuf and friends are probably a much better serialization system for chat messages.

Completely agreed.

I don't see why developers fear XML so much. I think it has to do with the fact that everything is built by web developers now. Sockets have been replaced by sockets and concise protocols have been replaced by messy HTTP requests. I wonder how long it'll be before ISPs start blocking any traffic not directed towards port 80/443.

That's pretty backwards IMO. Have you ever seen what SOAP requests actually look like? It's like a complete reimplementation of everything that HTTP does, in more verbose form... but it's only ever used on top of HTTP. The web/JSON stack has a long way to go to catch up with WS-* for messy overcomplication (and I say that as someone who thinks WS-* is not actually as bad as it's generally considered).

djur4• 5 years ago

I don't see why developers fear XML so much. I think it has to do with the fact that everything is built by web developers now.

I heard exactly this same thing 15 years ago from a mainframe programmer I was working with on an integration project, but flipped around: "this XML nonsense... you web developers want everything to look like HTML!" Wasn't a good look then, isn't a good look now.

1vuio0pswjnm7• 5 years ago

I saw this earlier today as hoytech's github was on HN front page: https://github.com/hoytech/serialipedia

Curious how would HN readers rate YAML vs CBOR.

TinyCBOR has a json2cbor utility which uses cjson. Is there a similiar utility for converting JSON to YAML.

nerdponx• 5 years ago

All of these complaints also seem like valid complaints about XML, except the thing about duplicate keys.

Also as far as I know, there is only one "JSONSchema", and it has a clearly defined version scheme. Are there other JSON Schema standards that I'm not aware of? I'd be interested to see them.

zkldi2• 5 years ago

does it always use UTF8 or does it break the standard?

It always uses UTF8, or it is invalid JSON and MUST NOT be parsed. For the same argument against XML, you could argue whether it actually honours the encoding field (i've found many cases where things lie in the encoding field, and still parse fine by XML parsers)

Which version of the JSON Schema does it use?

Quite literally the only one I have ever seen in use, ever, is JSON Schema[0].

Is it using a schema at all?

Most often, no.

What happens when "$ref" appears in the content body?

Nothing? JSON doesn't have lookups. There is no way to do lookups in JSON. If you do otherwise, you do not have JSON anymore.

How should I deal with duplicate keys?

This is an actual, real issue with JSON.

XML is a terrible format. It's filled to the brim with footgun features like entity expansion (only ever used to DOS servers), no data types (everything is a string, your parser just needs to know better), no meaningful reason to have both attributes and content, ambiguity between an array of one element and an element, etc. etc. etc.

[0] https://json-schema.org/

dwaite3• 5 years ago

XML was originally meant to be a document markup format, an evolution of SGML. While the markup was consistent, the interpretation of it was to be left to the actual document format definition.

Unfortunately, there was another camp which was trying to change it to not just be an extensible document interchange format but a data interchange format. These have different requirements.

For example, someone asked when you put data in an element vs an attribute. There was a push to provide guidance at one point based on SVG - everything other than text data (such as coordinates making up graphics) were attributes, such that a non-SVG view of the document would just be all of the textual data appended.

Most of the tooling issues came from this disconnect between document and data oriented interchange, such as tooling having options to toggle between interpretations of pretty fundamental concepts such as namespaces.

It also became pretty common for technologies to come out of the document-oriented space (e.g. XPath and XSLT) which led to it being basically impossible to compose or decompose XML-based data without potentially changing its meaning - unless you were doing so with tools that understood the interpretation of the data itself.

wusspuss6• 4 years ago

Now I need to find out which type of JSON an application uses (does it always use UTF8 or does it break the standard?

Utf-8 isn't standard to XML, it's required by XMPP. So in this scenario the same could be required from json.

Which version of the JSON Schema does it use?

No one uses those and everyone is happy. As for XML schemas, xmpp makes even harder to use than it makes everything else. Because it has this endless xml document that you end up having to parse with a streaming parser and those understandably don't support schemas. You end up having to build the little DOMs yourself, for every stanza. This isn't me theorizing, this is what clients (dino, gajim, tkabber) do. Now with the homebrew DOM you're unable to use xpath (unless again you implement it yourself which is no easy feat) which makes xml's awkwardness i.e. the fact that xml doesn't map into common language structures like dicts and lists so, so much worse.

How should I deal with duplicate keys?

Generally you don't because libraries don't even support that, and people generally are decent enough to never use those.

All serialization formats are stupid and messy in some way but I think XML gets a bad rep because of the defaults many parsing libraries picked (and the vulnerabilities they introduced).

And because it is messy. Not pushing for json in particular but even json doesn't have dtds, entities and so on and so forth. Thus parsing libraries don't implement such features, thus fewer vulnerabilities. Whereas vulns in xml parsers are basically the norm - look at python's out of the box xml parsers - there are four of them and each one has at least some vuln marked in the table in official python docs! Again, I'm no json fan, but it's already light years better than xml. "Any damn fool could produce a better data format than XML." Look at bittorrent's ad-hoc format, bencode. Even that is much better than xml. And in a high level language an entire parser would take you one evening to write with no prior knowledge of the format. And that implementation would be probably about the size of those ad-hoc DOM implementations in xmpp clients, that don't even do any parsing themselves, and would be much more pleasant to use.

dwaite3• 5 years ago

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.

"StartTLS" behavior is pretty broadly pushed for across the IETF. It usually goes hand in hand with SASL support in protocols like IMAP, SMTP, and XMPP.

This is really done for three reasons:

1. Detection via SRV with alternative 'secure' protocol versions requires twice as many DNS lookups 2. It makes it far more likely a client/server will ignore the text on avoiding insecure fallback. 3. It makes it harder for someone who wants to do introspection of traffic to do so cheaply by blocking the standard secure ports.

Rather than multiple ports, the trend has been toward requiring TLS now that TLS certificates are something that can often be automated for free. IMHO took considerable push-back to get a cleartext version of HTTP/2 approved.

dathinab5• 5 years ago

XMPP WG to allow on-connect TLS)

Wait what, since smtps STARTTLS is quite old I though it's by now well known that _any_ form of late TLS is a massive security vulnerability...

Some form of transport layer security not being the default and starting late would for me on itself enough of a reason to exclude XMPP from a lot of things.

MattJ1005• 5 years ago

I'm not aware of any vulnerability in XMPP due to the use of starttls. If you (or anyone) can prove otherwise, I'd be happy to see that. We can do coordinated disclosure across projects via the XSF.

stormbrew6• 5 years 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• 5 years ago

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.

Macha3• 5 years 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.

jeroenhd3• 5 years ago

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• 5 years ago

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.

Gigachad5• 5 years ago

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.

dane-pgp• 5 years ago

once a protocol becomes so embedded and fractured over multiple implementations, it becomes impossible to change.

Yet HTTP2 exists.

olah_15• 5 years ago

And matrix is proof this works. After trying it again this year, I think they have finally created a product which works really well.

The server and clients improved. The protocol did not improve.

The protocol is still designed to be a metadata sponge that proliferates this data as far as possible. There’s no way you’d design it in the same way today if you didn’t have intelligence funding in the earliest stages…

If XMPP clients improved, you’d say the same thing. “Wow, I guess XMPP works”

Macha3• 5 years 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• 5 years 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 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.

Arathorn3• 5 years 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-...), 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).

WhatIsDukkha2• 5 years ago

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

"""

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 :)

olah_15• 5 years ago

I want all my messages and history on all my devices wherever I login with the proper credentials

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

Gigachad5• 5 years ago

Thanks for all of your work on Matrix. I feel like after all these years, matrix has actually become a really great product/tool to use.

Also I hope you have most of this as a copypasta so time isn't wasted responding to the 1000th matrix FUD post.

deuill• 5 years ago

I agree that the bickering is tedious and old at this point (and perhaps has been since the start), but there is a sense that the technical arguments miss the point of what the contention is about. Now, my argument is based mostly on conjecture and observation, and I mainly use XMPP because Conversations is the only thing that runs on my Blackberry Q10 (another thread entirely); I have not much of a horse in the race in any other way.

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.

tgsovlerkhgsel• 5 years 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• 5 years ago

XML? Too much serialization overhead.

JSON? Still too much serialization.

BSON, there ye go.

blooalien• 5 years 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?

qwerty456127• 5 years ago

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

mnot• 5 years 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• 5 years 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/

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• 5 years 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.

octoberfranklin2• 5 years 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

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.

shmerl• 5 years 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.

frabbit• 5 years 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.

Sebb7674• 5 years 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• 5 years ago

What's wrong with IRC? Still works for me

octoberfranklin2• 5 years 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• 5 years ago

   says who?

INTPenis• 5 years 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• 5 years 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_15• 5 years 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.

wusspuss6• 4 years 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.

IETF should keep XMPP as IM standard, instead of Matrix

Related Stories