- cross-posted to:
- privacy@lemmy.ml
- technology@lemmy.world
- hackernews@derp.foo
- cross-posted to:
- privacy@lemmy.ml
- technology@lemmy.world
- hackernews@derp.foo
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).
The counter points on the site you posted are either completely expected or even desired properties of distributed systems (like not being able to force a delete or room closure on another server), or just problems with specific implementation details or insufficient clarity in the specs (like interop hickups or handling of media files). As far as I can tell nothing on the list is an “unfixable” protocol bug or core design flaw.
I agree that some are, and I think that the point being made in the article was that some of those properties might be surprising/deceiving for those who approach Matrix as another chat platform and not as a “distributed partially-replicated graph database”.
What I consider “unfixable” is the fact that we are 10 years into this now, and that nothing has improved substantially: I sent a message yesterday which took 10 hours to deliver, and an enormous amount of resources at that. Matrix isn’t ready for mass adoption, it is still not reliable, it broke on its promise to be the “protocols of all protocols” by failing to allocate the funds to maintain the bridge with the largest IRC network, and the developers don’t see the overwhelming complexity of it all as a bug, but as a feature. To me, it looks like Matrix will remain a mediocre platform for the general public, aka. those who want something fast and that just work and don’t care about “distributed partially-replicated graph database”.