And the pathetic thing is, if he had spent more time working on his "Grid protocol" instead of pointless nitpicking, maybe he would have a lot more credibility on the matter.
And you're mentioning it's outdated, which would be natural given that the last commit was over two years ago.
The parent comment is not using ad hom. They're critiquing the author's work and assessing their credibility based off of that. It's perfectly fine, and a great viewpoint to consider.
Under "Purpose and Scope":
> This document is a research paper by Libre Monde ASBL, nonprofit dedicated to protecting people's privacy. We had the need to document privacy points for The Grid Protocol project, fork of the Matrix protocol.
So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor. In fact, that might be why they are focusing on the issues they find, minors one included.
I was not aware of the Grid project, but they seem to make good points. Matrix is developed by a restricted group of people with a startup vibe and some cringy/questionable actions:
- spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have been a "simple" decentralized room extension of XMPP or any other established protocol) ; which takes us to the situation where Matrix has the exact same selling points which XMPP had 20 years ago... and keeps on reinventing the wheel
- pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix clients are all incompatible with one another (because only Element implements them all) and once they have been upgraded rooms cannot be downgraded so in many places only Element can chat
- requiring a web rendering engine for certain extensions (eg. Video chat) ; HTTP is a decent foundation for a protocol, but why is a Jitsi <iframe> considered a decent extension mechanism? it will just harm security/privacy (through potential XSS) and make it near-impossible for clients to be implemented without a Chrome-based engine, reinforcing Google's monopoly on the web
- putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms; beyond clients, investing in bridging with useless platforms like Microsoft Teams (though i did not find the code for that) while neglecting interop with open protocols like IRC/XMPP (relations with IRC/XMPP people are notoriously not very good though i hope it will improve over time)
All in all, i'm very glad matrix exists because they have popularized bridging and they do care for UX concerns like Spaces. But claiming people who forked the project because of political and technical disagreements are biased because they are a "competitor" is itself a very biased position based on the idea that only one true protocol must remain and others are heretics trying to undermine our technical purity (for their economic gain).
I wish we could have people from different protocols sitting across the table and working on interop so we can stop arguing about which network is best.
I don't get it. XMPP had MEGOLM, cross signing, decentralized chat rooms, good iOS support in practice, very simple sync of e2ee chat history, ... 20 years ago?
> spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have been a "simple" decentralized room extension of XMPP or any other established protocol) ;
This simply so wrong: Matrix was created exactly because if the failure of existing protocols [0]. And the mentioned extension was one failure in their mind.
[0]: https://matrix.org/faq/#why-has-no-one-done-this-before%3F
And imho it was the best thing to do. You don't repair a car if repairing costs much more than getting a new one
> pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix
In fact there are 9 versions today. Though afaik only one of them was due to a broken consensus algorithm. Others exist for new features. Strangely I can use even the latest ones with alternative clients such as Fluffy Chat - contrary to your claims
> but why is a Jitsi <iframe> considered a decent extension mechanism
It is? Source needed
Native Matrix video chat is being implemented as of now
> putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms
Also wrong: Element has a native Android and a native iOS clie t
hrm, maybe this was true a few years ago?
Element currently develops two web clients. Element Web: https://matrix.org/docs/projects/client/element and Hydrogen: https://matrix.org/docs/projects/client/hydrogen
Element also sponsors development of at least one other community web client that I know of.
Meanwhile, you can find Element's Android client here: https://matrix.org/docs/projects/client/element-android
And the iOS client here: https://matrix.org/docs/projects/client/element-ios
Within Element, new features are developed in cross-functional teams and released in tandem; e.g. Spaces was released on web and mobile at the same time.
On performance - there are definitely some performance issues with matrix clients in general, particularly larger rooms and accounts which are in many rooms. This is an active focus of development, e.g. see work on sync v3, a more efficient matrix sync protocol https://github.com/matrix-org/sync-v3
Disclaimer: I am an Element employee
The clean rooms approach is a good thing I think. Xmpp is becoming a pileup of different add-ons and suffers from the same issues you mention for matrix (not all features supported by all clients). Probably in a worse way.
I know the reluctance of IRC operators to allow (global) matrix bridges is often a case of different paradigms. On IRC a conversation can only be seen by users who are present at the time. A user joining a bridged matrix room can see the entire history from before they joined. This changes the privacy model a lot (insofar as IRC has any semblance of privacy, but whatever is there is regarded as very important). People running their own Heisenbridge puppeting bridges solves this issue though.
I'm not a matrix dev but I do like it, especially the phenomenon of bridges.
This is not the case, Matrix rooms can be set to allow viewing history only from joining time on. And that is how IRC bridge rooms are mostly configured, indeed based on policies from the bridged IRC networks.
Perhaps this was only introduced later? I'm talking about 3 years ago. But good to see this was fixed.
This is false. Clients don't do state res, servers do. Clients don't care.
The amount of incorrect info in the GP post is very unfortunate - although I too wish that open standard comms protocols spent more time collaborating than spitting at each other.
On the one hand, of course I love that people have the means to audit assumptions.
Both the ability to do so w.r.t the project being transparent and open, but also through time and technical ability.
I am, however, a little upset when people poke at minor issues (that they themselves see as minor) and speak at length about them. *not* because those issues should not be addressed, but because it gives ammunition for people who recommend closed platforms, or more opportunity for people to think of the community as being more divided than it really is.
The more uncertainty a thing is surrounded by: the more people are likely to just say "fuck it" and choose any option as long as it works, and guess what works? Closed platforms, especially those with coherent messaging like facebook or whatsapp.
So, with that in mind: Kudos for such an analysis, but be mindful that such a lengthy document that discusses minor issues can actually harm the matrix project.