Live data from Hacker News

Matrix 1.0 – Are We Ready Yet?

matrix.org

201–208 of 208 posts

Re: Matrix 1.0 – Are We Ready Yet?

#201
post #30
post #17

Earlier quoted context omitted.

To quote one of the follow up comments from the author: > If you go to matrix.org and look at the list of about a dozen or so servers: you will find that none of them actually work except the reference implementation, and maybe sometimes Construct. Even thus, the phrase "able to build" is questionable. I have spent months reverse-engineering their software and its interactions before, and after, it was at all documen…

The server-to-server specification was only formally released on February 5 of this year. Before that, it was certainly necessary to do reverse-engineering of synapse in order to build a HS, but it no longer is. The lack of server implementations just over a month after the release of the spec isn't good evidence of a bad spec. I strongly disagree with Jason's (who has been openly hostile to most of the matrix commun…

As the author of mxhsd [1] and Gridepo [2], I can sadly confirm Jason's claims that it is STILL necessary to reverse engineer to talk to the existing federation.

Synapse doesn't follow the spec, which is a fact I'm experiencing every day. But more to that, there is no desire from its developers to ever comply with the spec, rather than changing the spec on a whim.

And that are the reasons why making a HS is not possible: endless moving target.

[1]: https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo

Re: Matrix 1.0 – Are We Ready Yet?

#202
post #57
post #8

I had a pretty positive view of Matrix until I came across this post and the follow up responses from the developer behind an unofficial Matrix server implementation: https://news.ycombinator.com/item?id=19365968 I'd say tread carefully given their apparent hostility towards competing server implementations, which is literally the only thing that makes the protocol meaningfully "federated" to begin with. This part in…

I'm one of the people in that thread and I'm unconvinced by Jason's insinuations regarding the hostility of the New Vector team. From everything I've seen, interoperability and federation is extremely important for New Vector. The fact that Matrix is a rather innovative and semi-research project has to be taken into account. For instance, here[1] is the github thread on verifying event hashes which he refers to in th…

And here is three documents/issues that all related to synapse breaking systems in the federation, despite repeated extensive technical feedback.

And to this day, despite people that keep on reporting about the issue, nothing is done to actually solve the problem.

https://github.com/matrix-org/matrix-doc/issues/1194 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/matrix-doc/pull/1915

If interoperability and federation is important, why push changes that break those, and do nothing for >6 months?

Re: Matrix 1.0 – Are We Ready Yet?

#203
post #9
post #8

I had a pretty positive view of Matrix until I came across this post and the follow up responses from the developer behind an unofficial Matrix server implementation: https://news.ycombinator.com/item?id=19365968 I'd say tread carefully given their apparent hostility towards competing server implementations, which is literally the only thing that makes the protocol meaningfully "federated" to begin with. This part in…

I would be interested in knowing whether anyone else has confirmed these accusations or created a writeup as to why the protocol is insecure.

It also has very questionable choices towards respect of Privacy: https://github.com/matrix-org/synapse/issues/4540

Re: Matrix 1.0 – Are We Ready Yet?

#204
post #79

Earlier quoted context omitted.

No, you don't need a blockchain for decentralization. Also, you don't need a blockchain[0]. [0]: https://thomaslarock.com/2018/11/no-you-dont-need-a-blockcha...

I believe you missed a joke.

Gosh, I did miss it actually, my bad. Mild autism, I suppose, I often take words literally, esp. when there are no facial/voice tone cues.

Re: Matrix 1.0 – Are We Ready Yet?

#205
post #9

Earlier quoted context omitted.

I would be interested in knowing whether anyone else has confirmed these accusations or created a writeup as to why the protocol is insecure.

I can confirm. One of the write-ups I did: https://gist.github.com/maxidorius/b25769f1a89c8860b928babe7...

this write-up boils down to saying that servers that don't uphold server ACLs (server-bans) will leak messages from banned servers.

it's a feature, not a bug; if you want to deploy the nuclear option of a server-ban in a room, you also have to ban any other servers which don't know what a server-ban is.

Re: Matrix 1.0 – Are We Ready Yet?

#206
post #30

Earlier quoted context omitted.

The server-to-server specification was only formally released on February 5 of this year. Before that, it was certainly necessary to do reverse-engineering of synapse in order to build a HS, but it no longer is. The lack of server implementations just over a month after the release of the spec isn't good evidence of a bad spec. I strongly disagree with Jason's (who has been openly hostile to most of the matrix commun…

As the author of mxhsd [1] and Gridepo [2], I can sadly confirm Jason's claims that it is STILL necessary to reverse engineer to talk to the existing federation. Synapse doesn't follow the spec, which is a fact I'm experiencing every day. But more to that, there is no desire from its developers to ever comply with the spec, rather than changing the spec on a whim. And that are the reasons why making a HS is not possi…

if anyone's curious about the unspecific complaints here, it transpires that the actual complaint is synapse had a bug where it some endpoints were called with a trailing slash when the spec said it shouldn't have one... it got fixed in https://github.com/matrix-org/synapse/pull/4840 and https://github.com/matrix-org/synapse/pull/4935.

Re: Matrix 1.0 – Are We Ready Yet?

#207
post #57

Earlier quoted context omitted.

I'm one of the people in that thread and I'm unconvinced by Jason's insinuations regarding the hostility of the New Vector team. From everything I've seen, interoperability and federation is extremely important for New Vector. The fact that Matrix is a rather innovative and semi-research project has to be taken into account. For instance, here[1] is the github thread on verifying event hashes which he refers to in th…

And here is three documents/issues that all related to synapse breaking systems in the federation, despite repeated extensive technical feedback. And to this day, despite people that keep on reporting about the issue, nothing is done to actually solve the problem. https://github.com/matrix-org/matrix-doc/issues/1194 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/matrix-doc/pull/1915 I…

fwiw, the linked MSC https://github.com/matrix-org/matrix-doc/pull/1915 solves the problem, is merged, and is implemented in https://github.com/matrix-org/synapse/pull/4982.

Yes, it would have been great to have done this sooner, but unfortunately fixing a bug which only impacts deactivating accounts when using custom identity servers took a while to get to the top of the todo list.

Re: Matrix 1.0 – Are We Ready Yet?

#208

Earlier quoted context omitted.

Matrix isn't really hostile to competing server implementations. If it were, then they wouldn't have spent a long time and a lot of effort to finalize the Server-to-Server spec r0.1, which anyone can implement [1]. And just to add my personal anecdote, Matthew (CEO of New Vector, co-founder of Matrix.org) is present quite often in the Matrix HQ chat room, and willing to field questions from anyone. Perhaps with sligh…

I am the author of the now-frozen mxhsd project [1] and its resurected version, Gridepo [2]. I have contributed several times to the specification, reported issues for the past two years and still, to this day, I can confirm that it is not possible to implement a Matrix server with the current specification that can talk to the reference implementation. Most fundamental problem: synapse doesn't sign the events like t…

I'm not aware of a bug in how synapse signs events, and whilst it's possible there's a bug there, we can't fix stuff which we're unaware of which hasn't been disclosed. (Max would probably claim he can't disclose because he's been banned from our Github for consistently being obstructive; unfortunately this is a case in point).

Edit: he might be talking about https://github.com/matrix-org/synapse/issues/4787? Except that was fixed a month ago...

In terms of "don't blindly believe what a for-profit is saying, especially one that is in full control of the said protocol", I'd agree, were it true. However:

* These days the protocol is controlled entirely by the non-profit Matrix Foundation.

* The majority (3 out of 5) of the Foundation's directors have zero affiliation to New Vector, the company that the core Matrix set up to try to keep the project funded.

* The governance of the foundation & protocol is entirely open, as per https://github.com/matrix-org/matrix-doc/blob/matthew/msc177...

* We're announcing the final board once formally appointed; due in the next few weeks.

Meanwhile, it's also true to say that you shouldn't believe the skewed perspective of a disgruntled ex-community member with a chip on their shoulder, who is trying to plug their hostile fork: https://news.ycombinator.com/item?id=19473694.

Post reply on HN