4 ms·

> So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor. I was not aware of the Grid project, but they

> So seems that they probably won't have issues with that it might harm Matrix, as they are a direct competitor. 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.

GekkePrutser 5y ago
The Jitsi thing is going away, matrix already has its own video chat for 1:1 chats, and it's coming for rooms soon too. The Jitsi option was a temporary setup. 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.
- Maakuth 5y ago
  > A user joining a bridged matrix room can see the entire history from before they joined. 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.
  - GekkePrutser 5y ago
    Ah ok I remember this was a problem that was mentioned by the hackint network when people wanted to add a bridge there. We moved our community to OFTC as a result. Perhaps this was only introduced later? I'm talking about 3 years ago. But good to see this was fixed.
gefhfff 5y ago
> 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 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 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
- ninchuka 5y ago
  I feel like they are just throwing out lots of old information they read without checking if its still true, since its up to room version 9 now :P and like you said they are working on native video calls in matrix
ryukafalz 5y ago
> 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 This is false. Clients don't do state res, servers do. Clients don't care.
- pkulak 5y ago
  Yeah, I didn't want to say anything because I'm no expert, but as far as I can tell, Matrix clients use a Rest API. It's not like they are resolving state deltas locally or something. It seems like the big complexity right now is the encryption, since that, by definition, has to happen on the client. There's a concerted effort, however, to make that as easy as possible with shared libraries and such.
- Arathorn 5y ago
  Meanwhile on the serverside, there have only been two versions of state resolution; the original beta version that turned out to be buggy, and the current fixed one which has been heavily scrutinized and is okay: https://matrix.org/blog/2020/06/16/matrix-decomposition-an-independent-academic-analysis-of-matrix-state-resolution https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i.... 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.
novocaine 5y ago
> putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms; hrm, maybe this was true a few years ago? Element currently develops two web clients. Element Web: https://matrix.org/docs/projects/client/element https://matrix.org/docs/projects/client/element and Hydrogen: https://matrix.org/docs/projects/client/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 https://matrix.org/docs/projects/client/element-android And the iOS client here: https://matrix.org/docs/projects/client/element-ios 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 https://github.com/matrix-org/sync-v3 Disclaimer: I am an Element employee

GekkePrutser 5y ago

The Jitsi thing is going away, matrix already has its own video chat for 1:1 chats, and it's coming for rooms soon too. The Jitsi option was a temporary setup. 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.

Maakuth 5y ago
> A user joining a bridged matrix room can see the entire history from before they joined. 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.
- GekkePrutser 5y ago
  Ah ok I remember this was a problem that was mentioned by the hackint network when people wanted to add a bridge there. We moved our community to OFTC as a result. Perhaps this was only introduced later? I'm talking about 3 years ago. But good to see this was fixed.

gefhfff 5y ago

> 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 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 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

ninchuka 5y ago
I feel like they are just throwing out lots of old information they read without checking if its still true, since its up to room version 9 now :P and like you said they are working on native video calls in matrix

ryukafalz 5y ago

> 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 This is false. Clients don't do state res, servers do. Clients don't care.

pkulak 5y ago
Yeah, I didn't want to say anything because I'm no expert, but as far as I can tell, Matrix clients use a Rest API. It's not like they are resolving state deltas locally or something. It seems like the big complexity right now is the encryption, since that, by definition, has to happen on the client. There's a concerted effort, however, to make that as easy as possible with shared libraries and such.
Arathorn 5y ago
Meanwhile on the serverside, there have only been two versions of state resolution; the original beta version that turned out to be buggy, and the current fixed one which has been heavily scrutinized and is okay: https://matrix.org/blog/2020/06/16/matrix-decomposition-an-independent-academic-analysis-of-matrix-state-resolution https://matrix.org/blog/2020/06/16/matrix-decomposition-an-i.... 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.

novocaine 5y ago

> putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms; hrm, maybe this was true a few years ago? Element currently develops two web clients. Element Web: https://matrix.org/docs/projects/client/element https://matrix.org/docs/projects/client/element and Hydrogen: https://matrix.org/docs/projects/client/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 https://matrix.org/docs/projects/client/element-android And the iOS client here: https://matrix.org/docs/projects/client/element-ios 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 https://github.com/matrix-org/sync-v3 Disclaimer: I am an Element employee