3 ms·

From the post: > ...lays the groundwork for a more resilient technical foundation Let's hope the protocol improves

ezst 1y ago
Yeah, no. I lost hope that they have any idea of what they are doing, or any willingness to improve and drop out of the sunk cost fallacy that paralyses them. Every two years or so they break protocol and implementations with big promises that "this time the charm, finally", and it's essentially the same slow mess with some new bugs.
- deleted 1y ago
  [deleted]
jasonvorhe 1y ago
I have no hope for matrix. Good summary of what's wrong: https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg/ https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg...
- NetOpWibby 1y ago
  Poor performance, UX, and reliability issues. WELP, seems like XMPP is much simpler to use. For anyone who doesn't know the difference between XMPP and Matrix (like me): https://claude.ai/share/a2624334-d21e-455a-a1b3-9025c69a921a https://claude.ai/share/a2624334-d21e-455a-a1b3-9025c69a921a
- lordofgibbons 1y ago
  What do you recommend as a better (secure/private) alternative?
  - jasonvorhe 1y ago
    I haven't come around to actually look for an alternative but XMPP will the first I'll try.
  - ezst 1y ago
    I second the sibling comment recommending XMPP. Take a mature server like ejabberd, set up your DNS and firewall, and you are good to go. Easy, secure, extremely reliable and scalable. Matrix problem statement/what it set to do differently is "rooms should survive their server going down". Although nice-sounding, it's never realized in practice: your server going down means your account is unavailable too, and you can't use the network. Rooms syncing is essentially "old IRC net splits" with more steps (and much more RAM/CPU). This way of tackling this sort of "high availability" at the protocol level makes implementing the Matrix spec impossible (there is only one almost-compliant server implementation to talk with almost one feature-complete client, all by the same entity, selling it as opencore). Now compare that with the half dozen or so well-maintained XMPP servers (and plethora of clients), most of which support a form for HA/resilience that happens at runtime-level instead of protocol-level (via Erlang clustering/distributed JVM). In other words, if that's what you care about, XMPP implements Matrix mission statement better, more efficiently and with less organisational centralisation than Matrix.

ezst 1y ago

Yeah, no. I lost hope that they have any idea of what they are doing, or any willingness to improve and drop out of the sunk cost fallacy that paralyses them. Every two years or so they break protocol and implementations with big promises that "this time the charm, finally", and it's essentially the same slow mess with some new bugs.

deleted 1y ago
[deleted]

jasonvorhe 1y ago

I have no hope for matrix. Good summary of what's wrong: https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg/ https://xn--gckvb8fzb.com/giving-up-on-element-and-matrixorg...

NetOpWibby 1y ago
Poor performance, UX, and reliability issues. WELP, seems like XMPP is much simpler to use. For anyone who doesn't know the difference between XMPP and Matrix (like me): https://claude.ai/share/a2624334-d21e-455a-a1b3-9025c69a921a https://claude.ai/share/a2624334-d21e-455a-a1b3-9025c69a921a
lordofgibbons 1y ago
What do you recommend as a better (secure/private) alternative?
- jasonvorhe 1y ago
  I haven't come around to actually look for an alternative but XMPP will the first I'll try.
- ezst 1y ago
  I second the sibling comment recommending XMPP. Take a mature server like ejabberd, set up your DNS and firewall, and you are good to go. Easy, secure, extremely reliable and scalable. Matrix problem statement/what it set to do differently is "rooms should survive their server going down". Although nice-sounding, it's never realized in practice: your server going down means your account is unavailable too, and you can't use the network. Rooms syncing is essentially "old IRC net splits" with more steps (and much more RAM/CPU). This way of tackling this sort of "high availability" at the protocol level makes implementing the Matrix spec impossible (there is only one almost-compliant server implementation to talk with almost one feature-complete client, all by the same entity, selling it as opencore). Now compare that with the half dozen or so well-maintained XMPP servers (and plethora of clients), most of which support a form for HA/resilience that happens at runtime-level instead of protocol-level (via Erlang clustering/distributed JVM). In other words, if that's what you care about, XMPP implements Matrix mission statement better, more efficiently and with less organisational centralisation than Matrix.