12 ms·

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 implement

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 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 particular was deeply disturbing: > I can quote the CEO of new vector in an argument we had about the insecurities of the protocol and what needs to be done to fix them where he said "good luck talking to your own federation." That reveals a lot. Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol.

cetra3 8y ago
I would be interested in knowing whether anyone else has confirmed these accusations or created a writeup as to why the protocol is insecure.
- maxidorius 8y ago
  I can confirm. One of the write-ups I did: https://gist.github.com/maxidorius/b25769f1a89c8860b928babe795bbaaf https://gist.github.com/maxidorius/b25769f1a89c8860b928babe7...
  - Arathorn 8y ago
    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.
- maxidorius 8y ago
  It also has very questionable choices towards respect of Privacy: https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/synapse/issues/4540
baroffoos 8y ago
I think the situation is not that matrix.org is hostile to outside developers but that they are working on something new and rapidly changing and other implementations aren't able to keep up until the protocol changes slow down and the docs get better.
EvangelicalPig 8y ago
Damaging if true :/
Pneumaticat 8y ago
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.
meruru 8y ago
I think you're letting some rando's accusations color your perception of the project too much.
meditate 8y ago
I am not surprised at this and I am not sure why the Construct developer was either. Protocols like this during the initial growth phase have a ton of churn on the backend and because of that, reluctance to finalize any spec -- it's understood to be a moving standard. So presumably this person knew the risks.
Arathorn 8y ago
I'm the project lead for Matrix (and CEO of New Vector, the company which hires most of the core Matrix team) and can try to clarify this. 1. We don't have any hostility to alternative server implementations; it would be utterly idiotic to sabotage the project by doing so. Instead, we promote them, even when they're written by people who for whatever reason have issues with the project. For instance, if you look at https://matrix.org/blog/category/general/this-week-in-matrix/ https://matrix.org/blog/category/general/this-week-in-matrix... you can see us publishing almost weekly updates on Construct (the server written by the guy who is levelling the accusations here). Meanwhile, Construct appears to work well enough to talk to the rest of Matrix in practice. 2. Yup, there have been some security issues pre-1.0 in Matrix around federation, particularly around state resets (thinkos in the state merge resolution algorithm), event ID collision, incorrectly trusting potentially malicious DAG depth parameters, and issues around the perspectives logic. As far as we're aware, these have all been fixed now, or will be once everyone has migrated from perspectives to real TLS, as per the original article - hence us making a big noise about it with AreWeReadyYet.com. Most of the gory details are at: https://github.com/matrix-org/matrix-doc/issues/1442 https://github.com/matrix-org/matrix-doc/issues/1442, https://github.com/matrix-org/matrix-doc/pull/1659 https://github.com/matrix-org/matrix-doc/pull/1659, https://github.com/matrix-org/matrix-doc/issues/1229 https://github.com/matrix-org/matrix-doc/issues/1229 and https://github.com/matrix-org/matrix-doc/pull/1711 https://github.com/matrix-org/matrix-doc/pull/1711 respectively. You can also see me talking through these issues one by one on the main stage at FOSDEM, starting around https://youtu.be/C2eE7rCUKlE?t=2035 https://youtu.be/C2eE7rCUKlE?t=2035. 3. I can't remember the precise context where I said "good luck talking to your own federation", but I suspect it was the result of a disagreement over how federation should be designed - probably over whether DAG depth parameters should be calculated locally or proposed remotely and then validated. We chose one solution, there was a lengthy disagreement, my eventual response on giving up on the argument was "okay, if you want to do it the other way, good luck with that" or words to that effect. For context, the guy levelling the accusations here is also responsible for maliciously exploiting the security issues on discovering them (e.g. https://matrix.org/blog/2018/06/14/security-update-synapse-0-31-2/ https://matrix.org/blog/2018/06/14/security-update-synapse-0...). He is also banned from our github and the core-team chatrooms on Matrix after exhibiting pretty much every flavour of obnoxious and destructive behaviour, culminating with ad hominems against me and most of the individuals on the core team, illustrating his points with hardcore porn, and asking how we're going to compensate him for not launching further exploits. He's also filled up the network with sockpuppet accounts to spam his project (despite us, for better or worse, already promoting it on the weekly blog), and I'd assume he's also seeding sockpuppets on HN too. So, TL;DR: whilst it's true that pre-1.0 we had some security issues around federation, we believe they are now fixed (or will be, once we've upgraded all the rooms to 1.0). Meanwhile, be aware that the complaints are coming from a deeply disingenuous and malicious source.
jancsika 8y ago
> Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol. It depends on what exactly the complainant was proposing to change in the protocol. There are no details in the link you provided about what was insecure about the protocol at that time, not to mention the proposed fixes. Is there another link for that? > Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol. Are you talking about the development process that led of the 1.0 protocol, or the spec itself?
subway 8y ago
It seems like a few folks have been burned by the failure to put the spec before the implementation. Another example: Kamax provides mxisd[1], the only federated identity server (the official identity server is/was controlled by vector, and doesnt openly federate). They had to give up on mxhsd[2], their home server implementation due to spec inadequacies, and ended up forking the spec into Grid[3] [1] https://github.com/kamax-matrix/mxisd https://github.com/kamax-matrix/mxisd [2] https://github.com/kamax-matrix/mxhsd https://github.com/kamax-matrix/mxhsd [3] https://gitlab.com/kamax-io/grid/gridepo https://gitlab.com/kamax-io/grid/gridepo
- Arathorn 8y ago
  Matrix has always deliberately put implementation before formalising the spec, because there's no point in speccing things which haven't first been tested in the wild. This is also partially influenced by observing that many XMPP XEPs seem to have lacked a proven implementation at the point of being specced, contributing to the fragmentation of the standard. Now, the reason that we didn't formalise the federation spec until very recently (Jan 2019 - https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/ https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/) is because the implementation in the wild was showing problems which we wanted to resolve first. Now, this took ages to do, mainly because the team got mired in technical debt in Synapse and keeping the matrix.org server running, whilst trying to support the overall featureset (E2E etc) needed for Matrix to be successful. But we made it in the end. Meanwhile, it's true that server implementors got bitten by the lack of formal spec. The Ruma project for instance went on hiatus until a stable spec was released. Meanwhile unfortunately the mxhsd project lost patience and forked. In an ideal world we'd have been able to move faster on releasing the stable federation spec, but the reality is that Matrix is a lot more than the federation API (although server implementors obviously focus particularly on it): we've put a lot of work into the CS API, E2E encryption, AS API, bridges, bots, reference clients etc too. History will tell if in the long term we got the prioritisation right. Meanwhile, the federation API should now be sufficiently specced for server implementors to be able to successfully implement it - see https://matrix.org/docs/spec/server_server/r0.1.1.html https://matrix.org/docs/spec/server_server/r0.1.1.html if you're interested.
Perceptes 8y ago
I'm the original creator of Ruma, another homeserver implementation, and our project has received nothing but support and appreciation from the Matrix team. It's true that Synapse is the only homeserver that is in a "finished" state, but that has more to do with Matrix being young, the spec still needing work (although it's come a long way recently), and the lack of time and resources to complete such a big project if it's not your full time job.
- jeltz 8y ago
  Is the Ruma project still alive? I liked your website and your goals but last I checked there was very little activity.
  - Perceptes 8y ago
    Yes, it's alive. We've been on a long hiatus while we wait for the dust to settle with async code in the Rust ecosystem. This is the GitHub issue that best tracks our ongoing blockers: https://github.com/ruma/ruma/issues/189 https://github.com/ruma/ruma/issues/189
- maxidorius 8y ago
  As the author of one frozen homeserver [1] and an hybrid implementation [2], with various work made all across the spec, I'm not shy to say synapse is the only homeserver because it talks its own dialect of the spec, not because there wasn't attempts to build something else. [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
feanaro 8y ago
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 that HN thread. From what I can see, he notes some of his (insightful!) thoughts on the matter, nothing but a civil discussion ensues, with parts of his suggestions getting implemented and others being worked on. [1]: https://github.com/matrix-org/synapse/issues/1252 https://github.com/matrix-org/synapse/issues/1252
- maxidorius 8y ago
  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/matrix-doc/issues/1194 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/matrix-doc/pull/1915 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?
  - Arathorn 8y ago
    fwiw, the linked MSC https://github.com/matrix-org/matrix-doc/pull/1915 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 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.
ATsch 8y ago
I think it's easy for bystanders to mistake hostility towards the developer of construct as hostility towards the project or the specific implementation without knowing the full context, however this is not the case. The developer is without doubt a brilliant individual, however also extremely toxic. Not in the Linus sense, but in the Terry A Davis sense. If anything, I think the matrix team has been too reasonable with him. He actually agreed with that himself, making fun of the team for not having the integrity to ban him out of sympathy for his situation and wanting to avoid the optics of banning a developer of an alternative server. I have a lot of sympathy him as it sounds like he has a very serious substance abuse issue. I really really hope that he can beat the problems he faces, and I'm sure he will be accepted by the community again if he does. I understand that he is not fully under control of his situation but until he is, I don't think he should be tolerated when his presence is so hurtful to his victims and the community as a whole. Here's some fun highlights I've experience first hand for context: - spamming rooms with BSDM porn - spamming rooms with links to his implementation - hurling sexist abuse at a female matrix team member - hurling sexually abusive language and rape threats at people - numerous other drug-fueled breakdowns and caps locks tirades - sockpuppeting and circumventing bans - attempting to blackmail the team with his exploits - deliberately bricking rooms

cetra3 8y ago

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

maxidorius 8y ago
I can confirm. One of the write-ups I did: https://gist.github.com/maxidorius/b25769f1a89c8860b928babe795bbaaf https://gist.github.com/maxidorius/b25769f1a89c8860b928babe7...
- Arathorn 8y ago
  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.
maxidorius 8y ago
It also has very questionable choices towards respect of Privacy: https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/synapse/issues/4540

baroffoos 8y ago

I think the situation is not that matrix.org is hostile to outside developers but that they are working on something new and rapidly changing and other implementations aren't able to keep up until the protocol changes slow down and the docs get better.

EvangelicalPig 8y ago

Damaging if true :/

Pneumaticat 8y ago

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.

meruru 8y ago

I think you're letting some rando's accusations color your perception of the project too much.

meditate 8y ago

I am not surprised at this and I am not sure why the Construct developer was either. Protocols like this during the initial growth phase have a ton of churn on the backend and because of that, reluctance to finalize any spec -- it's understood to be a moving standard. So presumably this person knew the risks.

Arathorn 8y ago

I'm the project lead for Matrix (and CEO of New Vector, the company which hires most of the core Matrix team) and can try to clarify this. 1. We don't have any hostility to alternative server implementations; it would be utterly idiotic to sabotage the project by doing so. Instead, we promote them, even when they're written by people who for whatever reason have issues with the project. For instance, if you look at https://matrix.org/blog/category/general/this-week-in-matrix/ https://matrix.org/blog/category/general/this-week-in-matrix... you can see us publishing almost weekly updates on Construct (the server written by the guy who is levelling the accusations here). Meanwhile, Construct appears to work well enough to talk to the rest of Matrix in practice. 2. Yup, there have been some security issues pre-1.0 in Matrix around federation, particularly around state resets (thinkos in the state merge resolution algorithm), event ID collision, incorrectly trusting potentially malicious DAG depth parameters, and issues around the perspectives logic. As far as we're aware, these have all been fixed now, or will be once everyone has migrated from perspectives to real TLS, as per the original article - hence us making a big noise about it with AreWeReadyYet.com. Most of the gory details are at: https://github.com/matrix-org/matrix-doc/issues/1442 https://github.com/matrix-org/matrix-doc/issues/1442, https://github.com/matrix-org/matrix-doc/pull/1659 https://github.com/matrix-org/matrix-doc/pull/1659, https://github.com/matrix-org/matrix-doc/issues/1229 https://github.com/matrix-org/matrix-doc/issues/1229 and https://github.com/matrix-org/matrix-doc/pull/1711 https://github.com/matrix-org/matrix-doc/pull/1711 respectively. You can also see me talking through these issues one by one on the main stage at FOSDEM, starting around https://youtu.be/C2eE7rCUKlE?t=2035 https://youtu.be/C2eE7rCUKlE?t=2035. 3. I can't remember the precise context where I said "good luck talking to your own federation", but I suspect it was the result of a disagreement over how federation should be designed - probably over whether DAG depth parameters should be calculated locally or proposed remotely and then validated. We chose one solution, there was a lengthy disagreement, my eventual response on giving up on the argument was "okay, if you want to do it the other way, good luck with that" or words to that effect. For context, the guy levelling the accusations here is also responsible for maliciously exploiting the security issues on discovering them (e.g. https://matrix.org/blog/2018/06/14/security-update-synapse-0-31-2/ https://matrix.org/blog/2018/06/14/security-update-synapse-0...). He is also banned from our github and the core-team chatrooms on Matrix after exhibiting pretty much every flavour of obnoxious and destructive behaviour, culminating with ad hominems against me and most of the individuals on the core team, illustrating his points with hardcore porn, and asking how we're going to compensate him for not launching further exploits. He's also filled up the network with sockpuppet accounts to spam his project (despite us, for better or worse, already promoting it on the weekly blog), and I'd assume he's also seeding sockpuppets on HN too. So, TL;DR: whilst it's true that pre-1.0 we had some security issues around federation, we believe they are now fixed (or will be, once we've upgraded all the rooms to 1.0). Meanwhile, be aware that the complaints are coming from a deeply disingenuous and malicious source.

jancsika 8y ago

> Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol. It depends on what exactly the complainant was proposing to change in the protocol. There are no details in the link you provided about what was insecure about the protocol at that time, not to mention the proposed fixes. Is there another link for that? > Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol. Are you talking about the development process that led of the 1.0 protocol, or the spec itself?

subway 8y ago

It seems like a few folks have been burned by the failure to put the spec before the implementation. Another example: Kamax provides mxisd[1], the only federated identity server (the official identity server is/was controlled by vector, and doesnt openly federate). They had to give up on mxhsd[2], their home server implementation due to spec inadequacies, and ended up forking the spec into Grid[3] [1] https://github.com/kamax-matrix/mxisd https://github.com/kamax-matrix/mxisd [2] https://github.com/kamax-matrix/mxhsd https://github.com/kamax-matrix/mxhsd [3] https://gitlab.com/kamax-io/grid/gridepo https://gitlab.com/kamax-io/grid/gridepo

Arathorn 8y ago
Matrix has always deliberately put implementation before formalising the spec, because there's no point in speccing things which haven't first been tested in the wild. This is also partially influenced by observing that many XMPP XEPs seem to have lacked a proven implementation at the point of being specced, contributing to the fragmentation of the standard. Now, the reason that we didn't formalise the federation spec until very recently (Jan 2019 - https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/ https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/) is because the implementation in the wild was showing problems which we wanted to resolve first. Now, this took ages to do, mainly because the team got mired in technical debt in Synapse and keeping the matrix.org server running, whilst trying to support the overall featureset (E2E etc) needed for Matrix to be successful. But we made it in the end. Meanwhile, it's true that server implementors got bitten by the lack of formal spec. The Ruma project for instance went on hiatus until a stable spec was released. Meanwhile unfortunately the mxhsd project lost patience and forked. In an ideal world we'd have been able to move faster on releasing the stable federation spec, but the reality is that Matrix is a lot more than the federation API (although server implementors obviously focus particularly on it): we've put a lot of work into the CS API, E2E encryption, AS API, bridges, bots, reference clients etc too. History will tell if in the long term we got the prioritisation right. Meanwhile, the federation API should now be sufficiently specced for server implementors to be able to successfully implement it - see https://matrix.org/docs/spec/server_server/r0.1.1.html https://matrix.org/docs/spec/server_server/r0.1.1.html if you're interested.

Perceptes 8y ago

I'm the original creator of Ruma, another homeserver implementation, and our project has received nothing but support and appreciation from the Matrix team. It's true that Synapse is the only homeserver that is in a "finished" state, but that has more to do with Matrix being young, the spec still needing work (although it's come a long way recently), and the lack of time and resources to complete such a big project if it's not your full time job.

jeltz 8y ago
Is the Ruma project still alive? I liked your website and your goals but last I checked there was very little activity.
- Perceptes 8y ago
  Yes, it's alive. We've been on a long hiatus while we wait for the dust to settle with async code in the Rust ecosystem. This is the GitHub issue that best tracks our ongoing blockers: https://github.com/ruma/ruma/issues/189 https://github.com/ruma/ruma/issues/189
maxidorius 8y ago
As the author of one frozen homeserver [1] and an hybrid implementation [2], with various work made all across the spec, I'm not shy to say synapse is the only homeserver because it talks its own dialect of the spec, not because there wasn't attempts to build something else. [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

feanaro 8y ago

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 that HN thread. From what I can see, he notes some of his (insightful!) thoughts on the matter, nothing but a civil discussion ensues, with parts of his suggestions getting implemented and others being worked on. [1]: https://github.com/matrix-org/synapse/issues/1252 https://github.com/matrix-org/synapse/issues/1252

maxidorius 8y ago
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/matrix-doc/issues/1194 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/matrix-doc/pull/1915 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?
- Arathorn 8y ago
  fwiw, the linked MSC https://github.com/matrix-org/matrix-doc/pull/1915 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 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.

ATsch 8y ago

I think it's easy for bystanders to mistake hostility towards the developer of construct as hostility towards the project or the specific implementation without knowing the full context, however this is not the case. The developer is without doubt a brilliant individual, however also extremely toxic. Not in the Linus sense, but in the Terry A Davis sense. If anything, I think the matrix team has been too reasonable with him. He actually agreed with that himself, making fun of the team for not having the integrity to ban him out of sympathy for his situation and wanting to avoid the optics of banning a developer of an alternative server. I have a lot of sympathy him as it sounds like he has a very serious substance abuse issue. I really really hope that he can beat the problems he faces, and I'm sure he will be accepted by the community again if he does. I understand that he is not fully under control of his situation but until he is, I don't think he should be tolerated when his presence is so hurtful to his victims and the community as a whole. Here's some fun highlights I've experience first hand for context: - spamming rooms with BSDM porn - spamming rooms with links to his implementation - hurling sexist abuse at a female matrix team member - hurling sexually abusive language and rape threats at people - numerous other drug-fueled breakdowns and caps locks tirades - sockpuppeting and circumventing bans - attempting to blackmail the team with his exploits - deliberately bricking rooms