Hacker News Reader

Comment by Andrew_nenakhov | Hacker News Reader

Matrix is not even a protocol. It is by far inferior to xmpp, especially regarding extendability, and the only flaw in XMPP is a rather lethargic council of elders that are not really interested in its development. This council is too be ignored, the base of the protocol is healthy.

View on HN

You say Matrix is not a protocol, and then you go on and compare it to another protocol. By your own logic, you are comparing apples and oranges here. Make up your mind, either it is a protocol or it isn't.

Oh, and Matrix is plenty extensible, for example via custom event types: https://spec.matrix.org/v1.1/client-server-api/#types-of-roo...

Matrix is a product developed by one entity that can be installed on premise and has an api. Different instances can communicate with each other. Mattermost also has it but we don't call it a protocol.

This is just not true. There are four main Matrix server implementations today: Synapse, Dendrite, Conduit and Construct. Conduit & Construct are written by entirely independent different parties; all four share zero code; and yet they all can communicate together (modulo beta-ness in some places).

(And aside from that, Mattermost doesn't have federation; different instances can not communicate with each other. Although we hope they'll implement Matrix eventually :)

Both third party implementations have beta status and all entirely independent implementations will be screwed and will stop working each time you decide to significantly change the spec in your monolithic protocil.

I know, you consider xep structure of XMPP to be a problem, 'because it is hard to orient in it', but in fact it is what makes XMPP so durable and capable to work in a real federated environment.

Matrix is working in a real federated environment between hundreds of servers

... between server instances provided by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1].

I can see zero problems with this decisive approach. /s

[1]: https://news.ycombinator.com/item?id=19421978

> between server instances provided by a single dominant vendor

No, any server instances provided by any vendor

> by a single dominant vendor, whose idea of federation is for everyone to update to the latest version of the spec or fall behind [1].

Server instance provider is not the same as software provider. Of course, you fall behind if you don't update. Time progresses, so does software.

> Of course, you fall behind if you don't update

In proper federated networks (email, xmpp), you don't.

Define proper :D

What I value with Matrix is progress

What you perceive as progress is just a sign of immaturity of an ecosystem. One player will ALWAYS move faster because he doesn't have to check with other participants, single-handedly self-defining specs and implementing them in own software. But reliance on this model will never allow another participants to enter, and it will always be a one-vendor vehicle.

Proper federated networks are ones that are already past this initial phase of fast progress and where participants have learned to work with each other.

Having progress (and thus the possibility of falling behind) doesn't say anything about the speed of progress.

> and it will always be a one-vendor vehicle.

You are clearly not speaking of Matrix: e.g. Element, Beeper, Dataport

How no progress ends up, can be observed with email and xmpp

> Proper federated networks are ones that are already past this initial phase of fast progress

That's made up by you. I claim proper federated networks are ones where you can fall behind

On the Matrix side of this: rather than spending time responding in detail I'll link to last week's iteration: https://news.ycombinator.com/item?id=29152551.

The TL;DR seems to be the concern that Matrix was created by an existing team of folks who worked together (we built VoIP stacks for telcos), and because 50% of the people in the Spec Core Team who define Matrix's direction are from that original team, they have a disproportionate influence over how the protocol develops.

The reality, as far as I can tell, is that we are incorporating the best proposals from across the whole community, wherever they come from, and the protocol is progressing steadily under this open governance model, and folks are constantly experimenting with new features under prefixes, which they propose MSCs (Matrix Spec Changes) for, and then get incorporated into the official spec once they're approved by the Spec Core Team (which requires 75% consensus).

We spent ages setting up https://matrix.org/foundation and trying to enshrine a fair and neutral governance process for the spec, and as far as I can tell it's overall working. The thread linked above gives examples of ways in which the process is working as intended.

Translation from prspeak: one closely integrated group has outsized influence on specification, and development is dominated by over commercial entity.

This is not how healthy federated networks work.

It's how they all start. "Rough consensus and running code."

The question is where to take it from that.

How is Matrix not a protocol? Because it has not been externally standardized?

That is interesting. Do you mean that the xmpp.org foundation is not a good custodian of the specs?

I think they are in some kind of lethargy, waking up each year and updating the compliance suite xeps.

TBH, (federated) chat/messaging is a solved problem since 1988 (IRC) or 1999 (XMPP), so I don't know what you expect

- group chats are shit

- message formatting is a mess

- device management is absent

- iOS apps can't really work with stock xeps

And the list is long, these are just the top problems. Luckily, this will likely change soon.

>Luckily, this will likely change soon.

Please elaborate.

Group chats, nicely working and with fallback for legacy clients. They are usable (without all features, of course) in Gajim/etc without doing anything:

Web client: https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f...

iOS client: https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f...

Message formatting (from web client, but is supported by all, actually): https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f...

Device management. Newly connected device is given a token, with a mechanism to prevent token duplication, and tokens can be revoked, resulting in device disconnection:

https://xmpp.redsolution.com/upload/4bddf4f264f5c6577f16551f...

This all is a work in progress, and we're aiming for an iOS version release in december or early next year.

Reply on news.ycombinator.com