Hacker News new | ask | show | jobs
by wusspuss 1523 days ago
>No matter how many times you say that, it still won't be true. A mere few minutes spent looking at the Matrix protocol and a few minutes spent looking at XMPP (if you can get past the fact that it's XML) will make that clear.

Maybe judge not by reading protocol description but by trying and using said protocol, like, chatting with people a lot? With the latter approach you'll notice a very handy feature of Matrix - not losing messages.

1 comments

I've experienced lost messages multiple times with Matrix, but I suspect this was due to the shitty clients rather than the protocol.

Not losing messages is also a feature of XMPP. In the distant past, especially before stream management, various kinds of network issue could certainly cause lost messages. These days, almost all implementations support the necessary features to make lost messages virtually impossible (of course, being federated, it's always possible that e.g. the remote server is permanently shut down just after successfully accepting your message, but that risk exists in all protocols including Matrix.)

Btw in Xabber we've decisively solved the message loss problem by introducing an extension that forces a client-set message id on a message and expects a server-set and a timestamp in a confirmation receipt.
Is this extension on the XMPP standards track? From my perspective, the message loss problem has been solved for some time using only standard extensions.
It will be, eventually. Though i think that XSF needs a revolt to stop them doing their thing the way they do. From what I get from their council meetings, they feel everything is fine. It is not.

Regarding the standard extensions, the most common way to prevent message loss is by using stream management, however there are edge cases in SM when the messages can still be lost in milti-device scenario. It is not surprising, SM was not meant to prevent message loss per se, just to resume a stream.

The main problem of XMPP on modern mobile devices is this: XMPP is designed to be always connected, while modern OS shut down apps when they are in background. So to make XMPP fit in the modern world we needed to make a transition from a resumption of stream to a synchronisation of state.