51 ms·

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 Serve

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 slightly less willingness when people start such accusations. Also, to address some of the technical issues, I think what they're talking about as "The blocks have hashes but their implementation does not check the hash" in the DAG is being fixed with the next (v3) room version [2]. Again, this development is all being done in public: see e.g. https://github.com/matrix-org/matrix-doc/pull/1659 https://github.com/matrix-org/matrix-doc/pull/1659 for the v3 room proposal. [1]: https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/ https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/ [2]: https://matrix.org/docs/spec/rooms/v3.html https://matrix.org/docs/spec/rooms/v3.html

fro0116 8y ago
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 documented in this so-called standard (by the way, it's just documentation of their software -- errata and all (and rather poor)). > Construct server is the single survivor out of the ones listed and even more who have attempted and given up early which we don't know about. That being said, it is still incomplete. A spec that "Anyone can implement" doesn't have much value if it's so bad/incomplete that in practice nobody else is actually able to create a complete working implementation of it as the post claims. And regardless of what they're planning on doing about any security issue, there's never a good reason for a discussion of a potential security issue in an "open" protocol to end in "good luck talking to your own federation." That's the behavior I'm pointing to that's hostile to competing server implementations. Of course, the quote could be taken out of context, or straight up made up. But until proven otherwise, I'm willing to give the benefit of the doubt to the small independent developer who seems to genuinely care enough about the openness of the protocol to build their own server implementation.
- Pneumaticat 8y ago
  At least from my perspective (I've never implemented the spec), I wouldn't call it just documentation [1]. Sure, there are likely some holes, but overall it seems like they've put a pretty good-faith effort into making it detailed enough for someone to implement. I feel like the difficulty comes mainly from the breadth/size of the spec. Which is a major issue (the Matrix.org team's own alternative server, Dendrite, has been slow to progress as well), but ultimately I'm not sure what they can really do about that considering one of their key tenets is to contain all the functionality out-of-the-box, so to speak (no extensions like XMPP). [1]: https://matrix.org/docs/spec/server_server/latest.html https://matrix.org/docs/spec/server_server/latest.html
- ADogWithPurpose 8y ago
  (Full disclosure - I'm contracted by New Vector to work on their integration services, but the below experiences are about my open source work which is unfunded and unrelated to my day job) I wanted to chime in as another developer in the server area. I've recently been working on a service that sits atop of an existing homeserver (like Synapse) to handle outgoing federation in .NET rather than Python (which has proven to give quite an nice performance boost). The project implements it's own federation and signing code. So far I've had to do almost no special casing around Synapse and followed the new S2S spec without issues, which has all been done in the open. The special casing I did have to do was brought before the team, judged a Synapse bug and will be fixed in an upcoming update. I don't have any evidence to point to whether the spec can be used to write a complete homeserver implementation, but everything so far has been done painlessly following the docs online. I believe that I could, with enough time. The project is developed by myself and another, and we've experienced no hostility from the team when asking questions about the protocol or the above bug. Quite the contrary, they were quick to help and the project has been promoted by matrix.org every week in the news blog posts. On the project itself, we hope one day to branch out from working on services that sit on top, to being a standalone homeserver (which should progress naturally. I don't foresee any spec related problems with doing this from reading the spec and chatting to folks in the community. So I felt it would be worth sharing my experiences as another server developer, albeit one that hasn't gotten as far in their journey yet.
- 8y ago
maxidorius 8y ago
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 the spec tell us to do it, making every event invalid. Whatever you sent that is spec compliant will be refused by synapse. So talking "synapse" is possible. Talking Matrix and be able to federate with the ecosystem is not. I wish people would not blindly believe what a for-profit is saying, especially one that is in full control of the said protocol, and start checking for themselves. [1]: https://github.com/kamax-matrix/mxhsd https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo https://gitlab.com/kamax-io/grid/gridepo
- Arathorn 8y ago
  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 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/msc1779/proposals/1779-open-governance.md 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 https://news.ycombinator.com/item?id=19473694.

fro0116 8y ago

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 documented in this so-called standard (by the way, it's just documentation of their software -- errata and all (and rather poor)). > Construct server is the single survivor out of the ones listed and even more who have attempted and given up early which we don't know about. That being said, it is still incomplete. A spec that "Anyone can implement" doesn't have much value if it's so bad/incomplete that in practice nobody else is actually able to create a complete working implementation of it as the post claims. And regardless of what they're planning on doing about any security issue, there's never a good reason for a discussion of a potential security issue in an "open" protocol to end in "good luck talking to your own federation." That's the behavior I'm pointing to that's hostile to competing server implementations. Of course, the quote could be taken out of context, or straight up made up. But until proven otherwise, I'm willing to give the benefit of the doubt to the small independent developer who seems to genuinely care enough about the openness of the protocol to build their own server implementation.

Pneumaticat 8y ago
At least from my perspective (I've never implemented the spec), I wouldn't call it just documentation [1]. Sure, there are likely some holes, but overall it seems like they've put a pretty good-faith effort into making it detailed enough for someone to implement. I feel like the difficulty comes mainly from the breadth/size of the spec. Which is a major issue (the Matrix.org team's own alternative server, Dendrite, has been slow to progress as well), but ultimately I'm not sure what they can really do about that considering one of their key tenets is to contain all the functionality out-of-the-box, so to speak (no extensions like XMPP). [1]: https://matrix.org/docs/spec/server_server/latest.html https://matrix.org/docs/spec/server_server/latest.html
ADogWithPurpose 8y ago
(Full disclosure - I'm contracted by New Vector to work on their integration services, but the below experiences are about my open source work which is unfunded and unrelated to my day job) I wanted to chime in as another developer in the server area. I've recently been working on a service that sits atop of an existing homeserver (like Synapse) to handle outgoing federation in .NET rather than Python (which has proven to give quite an nice performance boost). The project implements it's own federation and signing code. So far I've had to do almost no special casing around Synapse and followed the new S2S spec without issues, which has all been done in the open. The special casing I did have to do was brought before the team, judged a Synapse bug and will be fixed in an upcoming update. I don't have any evidence to point to whether the spec can be used to write a complete homeserver implementation, but everything so far has been done painlessly following the docs online. I believe that I could, with enough time. The project is developed by myself and another, and we've experienced no hostility from the team when asking questions about the protocol or the above bug. Quite the contrary, they were quick to help and the project has been promoted by matrix.org every week in the news blog posts. On the project itself, we hope one day to branch out from working on services that sit on top, to being a standalone homeserver (which should progress naturally. I don't foresee any spec related problems with doing this from reading the spec and chatting to folks in the community. So I felt it would be worth sharing my experiences as another server developer, albeit one that hasn't gotten as far in their journey yet.
8y ago

maxidorius 8y ago

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 the spec tell us to do it, making every event invalid. Whatever you sent that is spec compliant will be refused by synapse. So talking "synapse" is possible. Talking Matrix and be able to federate with the ecosystem is not. I wish people would not blindly believe what a for-profit is saying, especially one that is in full control of the said protocol, and start checking for themselves. [1]: https://github.com/kamax-matrix/mxhsd https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo https://gitlab.com/kamax-io/grid/gridepo

Arathorn 8y ago
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 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/msc1779/proposals/1779-open-governance.md 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 https://news.ycombinator.com/item?id=19473694.