Matrix, the open protocol for secure decentralised communications

Highlights include Sliding Sync (instant login/launch/sync), Native OIDC (industry-standard authentication), Native Group VoIP (end-to-end encrypted large-scale voice & video conferencing) and Faster Joins (lazy-loading room state when your server joins a room).

  • @u_tamtam@programming.dev
    7•1 year ago

    I won’t need to develop anything in response, because an open-standard (IETF) protocol for federated instant communications already existed long before Matrix, and as far as I can tell, from my experience of having administered XMPP and Matrix servers for hundred of users, nothing about Matrix, its design and its implementations makes it more desirable, more reliable, more resilient or more “future proof” than what XMPP came-up with a decade earlier.

    And I am aware that I sound like an old man yelling at clouds, I take comfort in the fact that more and more technically-versed people who look behind the marketing and buzz get to see what I know from experience: https://telegra.ph/why-not-matrix-08-07

      • @u_tamtam@programming.dev
        4•1 year ago

        Since its inception, Matrix has always been “months away” from cracking this very problem, I won’t hold my breath for this one, not after 10 years of kicking the same can down the road.

    • @lieuwex@discuss.tchncs.de
      1•1 year ago

      Is their shift key broken?

      Furthermore, this blog post has outdated information and many of their problems with Matrix are fundamental for federated protocols. Good luck removing an email sent to another server, for example. JSON form is very well defined.

      I can agree with the problem of DAG complexity building up, sure, but that is a tradeoff.

      • @u_tamtam@programming.dev
        1•1 year ago

        Is their shift key broken?

        Could be the result of repetitive strain injury, I’m not judging

        Furthermore, this blog post has outdated information and many of their problems with Matrix are fundamental for federated protocols. Good luck removing an email sent to another server, for example.

        Yup, I don’t think that’s the main argument, more a warning like “well if you normal folks were expecting anything else, that’s how it is and can’t be changed”

        JSON form is very well defined.

        Though that’s flawed/incomplete, and an essential reason for incompatibility between implementations

        I can agree with the problem of DAG complexity building up, sure, but that is a tradeoff.

        That’s my main issue, really. Basically, there’s no end in sight to the problem of inconsistent messages that can take minutes/hours/days to be delivered: Matrix just isn’t dependable for instant communications, by design. This rules it out of a ton of very significant and practical real world use cases and expectations. That’s not a system you can think typical modern users (used to their messages being either delivered instantly or not at all) to trust and to like once faced with these issues, not just once, but repeatedly. It is us, the world, being told again “Blockchain will solve all problems of centralization”, with a crowd of enthusiasts blinded by the hype embarking (taking hostage) their less savvy peers while the people being the steering wheel have no idea how to bring the car home. And worse, those people behind the steering wheel being in denial (or malicious, or incompetent), will keep telling you to just trust them, and that the problem is solved already while the evidence points in the other direction.