Comment by MattJ100 | Hacker News Reader

Comment by MattJ100 | Hacker News Reader

Parent Full thread

I'm not really sure how to silently lose messages in XMPP these days, if you use stream management (which everyone does[*]).

The last gap I'm aware of was that if you sent a message to someone on a remote server, and the remote server couldn't be connected to, your server would generate a delivery error (i.e. not silent). But* if you went offline before this delivery error reached you, you would never see it. These days such errors are stored in the user's message archive, and available to all your clients for synchronization purposes (so all of them can see that the message failed to deliver).

So with that said, I'm very interested in hearing any details you can provide about how to silently lose messages in modern XMPP. Clients involved, steps to reproduce, etc. Then we can produce actionable bug reports.

[*]: I believe Pidgin is still a notable exception here. Notable mainly because a lot of people still use it, even though its protocol plugin development has stalled somewhat for many years (the project is still being developed, but their focus has been on core/foundation improvements rather than keeping up with changes to modern internet messaging).

>So with that said, I'm very interested in hearing any details you can provide about how to silently lose messages in modern XMPP. Clients involved, steps to reproduce, etc. Then we can produce actionable bug reports.

Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday, ironically just as I tried to send the article to a friend to check out.

If I understand the two generals' problem correctly, there always is a way to silently lose messages, with any protocol, it's just that some approaches to not doing that are more reliable than others

> there always is a way to silently lose messages

That's a bit overgeneralized.

A simple protocol for message delivery that will not silently fail: resend it (presumably with a unique identifier of some sort to avoid duplication), pessimisticly and loudly pointing out "failure" (really: ambiguity of delivery), until you get a reciept of delivery.

What the two generals problem points out for this protocol is:

1. the sender of the reciept won't be certain that said reciept was recieved

2. the message may be successfully sent before the sender realizes it

3. if communication is permanently severed, the sender may forever be uncertain if the message ever got through or not (but this can be messaged loudly and pessimistically to the end user)

This creates design problems for coordination of consensus for things like database transactions, but a chat client failing to alert to potentially undelivered messages is just bad, not merely running afoul of some fundamental law of information science.

Of course, it's always possible to successfully send and recieve reciept of a message, only for the recipient's server to suddenly catch on fire and explode before backups are made, thus permanently losing any record of said message, but that's more of a "two generals and an assassin" problem, outside the scope of the original thought experiment. It is also, hopefully, a rarer scenario than packet loss.

> Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday

So it worked fine for some time, glitched one day, you presumably have done zero debugging as you have no logs or error messages to show us and somehow that means that clients "just lose messages".

Reply on news.ycombinator.com