Hacker News new | ask | show | jobs
by jhugo 1523 days ago
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.)
1 comments
Andrew_nenakhov 1523 days ago
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.
link
jhugo 1523 days ago
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.
link
Andrew_nenakhov 1523 days ago
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.

link