Hacker News Reader

Comment by emias | Hacker News Reader

> Have a single monolithic versioned protocol rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point.

I totally get where you came from, the fragmentation within the XMPP universe is annoying. The problem is that a monolithic spec doesn't solve this issue at all. It's not like code magically updates itself when you update a monolithic spec. The problem is missing manpower on the implementation side, and ditching modularity from the spec just makes it harder to cope with this in graceful ways.

View on HN

I'm not sure that the problem is missing manpower on the implementation side - it's more that it's hard to know as a developer which current blend of XEPs is the recommended combination and which might have the most chance of working between a given client & server (and server & client) combo.

Things like the XMPP compliance suite XEPs have helped a bit with this, but looking at the XEP list and trying to work out which XEPs you should be using on a given day is still daunting - as well as trying to track which clients are most likely to be supporting them.

The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind (rather than happening to chose not to implement some XEPs).

It boils down to a question of governance & social dynamics rather than anything related to writing code (magically or otherwise).

And admins will update their deployments instantly? Because of monolithic core? Interesting...

Yes, instantly. Or else they'll lose connectivity with central matrix server and 80% of users.

> I'm not sure that the problem is missing manpower on the implementation side

If it isn't, why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix and so many servers that aren't even capable of talking to matrix.org?

> why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix

Because the world is littered with unfinished projects? The key thing being that the authors KNOW very concretely that the project is unfinished, and there is a big red X next to the feature in question.

> so many servers that aren't even capable of talking to matrix.org?

Because we only released the first stable release of our federation API a month ago?

Reply on news.ycombinator.com