Hacker News new | ask | show | jobs
by rakoo 1137 days ago
I'm going to reply to some of your points because they're misguided:

> resilience against servers going down

The matrix model and the XMPP model are different. They solve orthogonal problems. Even the matrix people say it. That's like saying emails are better than github for collaboration because they are resilient against servers going down: it's true, but it's a different model. Not suitable for everyone.

> resilience against malicious federation

Wait for matrix to be taken up by big tech companies, you'll see spam flooding. I don't welcome it, but it's all about economics

> Json instead of XML

This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do.

> unified specification

Not all XMPP usages are the same. If you want messaging, you use the compliance suites, which are specs: https://xmpp.org/extensions/inbox/cs-2022.html#im

> handling of E2EE with multiple devices and message history

Has been working for years already: https://xmpp.org/extensions/xep-0384.html

> not need to rely on other servers for media access

Part of the standard installation of prosody and ejabberd, arguably two of the most known servers, for years. A few lines in the conf.

Matrix solves problems and creates others. Your information is outdated by almost a decade, which probably explains why you think matrix solves these.

1 comments

> > Json instead of XML > > This is both subjective and shows the lack of understanding that extensibility is, and how json only does 1/10 of what proper XML can do.

Can you elaborate on this a bit more? Specifically what can XML do that JSON can't?

I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages.

I even consider some things in XML (or at least in common implementations) to be nuisances, like collapsing elements into properties, or some accepting either or both without a schema, and I'm never sure what the precedence rules are. Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too.

> Specifically what can XML do that JSON can't?

Put XML inside XML, which is most useful for wrapping. Extensibility is built-in, so any parser knows it has to deal with namespaces; it doesn't depend on the flavor of the library.

> I know the feature set is technically larger (eg namespaces, schemas, etc), but AFAIK all those features aren't necessary for transporting messages.

It's not necessary for transporting messages, but both protocols go way beyond messaging. How do you send an invite for a party and a fallback if it isn't understood by the other side ? In XMPP you use namespaces; in JSON you have to define yet another schema that will only be used by your app and everyone else must copy it.

> Also, due to being a simpler spec, JSON is more widely available, and generally faster to parse too.

I'd like to see actual numbers of real software before believing the parsing speed even matters. A matrix server has to sync with dozens, sometimes hundreds of servers, some of them being extremely slow. I don't think the speed of parsing changes anything.

Plus, the spec is simpler indeed, but it is too simple. Namespaces solve a real problem, it's a mistake to not have them.