Display message errors in chat log (#382)

Unknown opened 5 years ago

When delivery of a message fails, this is not visible to the user. However, it would be much better to have an indication that the message was not delivered.

This indication should NOT be displayed if a Receipt has been received for that message already, and it should be reset if a Receipt arrives after the fact.

This is how it looks in yaxim:

P.S: you can test the behavior by sending messages to xmpp:reject@yax.im

Unknown commented 5 years ago

If the message is not delivered then it is marked by SiskinIM in the chat (if was stamped with ID, the response had a body and it was possible to be identified). In any other case message, the message is skipped.

If the message does not have a body element then in most cases it will not be stored in the offline storage anyway, so with iOS client (being mostly offline), the error would not be delivered anyway.

Unknown commented 5 years ago

I've tested the behavior by sending a message from Siskin to reject@yax.im, which will automatically send an error response to the message, referencing the original message id. However, Siskin didn't show any annotation to the message. Feel free to test yourself with the bot.

Unknown commented 5 years ago

As I've mentioned, Siskin adds an error if the response has a body, while reject@yax.im does not include body element in the response as I've checked.

Unknown commented 5 years ago

I haven't yet seen message errors with a body element in the wild, and I'm pretty sure that would be considered as non-standard by most. Have a look at RFC6120 §8.3 for the rules around message errors, they only suggest an <error> element (which can contain a text description of the error), and optionally returning back the original message XML.

Unknown commented 5 years ago

I know RFC and I also know that in most cases there is no specific <body/> element, but most of the implementations return the original message XML which contains <body/> element.

I've already mentioned, the message of type error without body element most likely will be dropped if the client is disconnected as message will not be saved to the offline storage by the server unless we add a hint to store a message. But this as well is not within RFC and would be considered non-standard.

So we can improve the client handling of the error (and we will), however, it will not improve the storage of error message while the client is not connected.

Unknown commented 5 years ago

Yes, I am aware of the sad situation with message errors that do not contain a body. I've actually just started a thread about this problem, in the hope to fix the respective standards. Feel free to chime in there :)

	Unknown opened 5 years ago When delivery of a message fails, this is not visible to the user. However, it would be much better to have an indication that the message was not delivered. This indication should NOT be displayed if a Receipt has been received for that message already, and it should be reset if a Receipt arrives after the fact. This is how it looks in yaxim: P.S: you can test the behavior by sending messages to xmpp:reject@yax.im
	Unknown commented 5 years ago If the message is not delivered then it is marked by SiskinIM in the chat (if was stamped with ID, the response had a body and it was possible to be identified). In any other case message, the message is skipped. If the message does not have a body element then in most cases it will not be stored in the offline storage anyway, so with iOS client (being mostly offline), the error would not be delivered anyway.
	Unknown commented 5 years ago I've tested the behavior by sending a message from Siskin to reject@yax.im, which will automatically send an error response to the message, referencing the original message id. However, Siskin didn't show any annotation to the message. Feel free to test yourself with the bot.
	Unknown commented 5 years ago As I've mentioned, Siskin adds an error if the response has a body, while reject@yax.im does not include body element in the response as I've checked.
	Unknown commented 5 years ago I haven't yet seen message errors with a body element in the wild, and I'm pretty sure that would be considered as non-standard by most. Have a look at RFC6120 §8.3 for the rules around message errors, they only suggest an `<error>` element (which can contain a text description of the error), and optionally returning back the original message XML.
	Unknown commented 5 years ago I know RFC and I also know that in most cases there is no specific `<body/>` element, but most of the implementations return the original message XML which contains `<body/>` element. I've already mentioned, the message of type error without body element most likely will be dropped if the client is disconnected as message will not be saved to the offline storage by the server unless we add a hint to store a message. But this as well is not within RFC and would be considered non-standard. So we can improve the client handling of the error (and we will), however, it will not improve the storage of error message while the client is not connected.
	Unknown commented 5 years ago Yes, I am aware of the sad situation with message errors that do not contain a body. I've actually just started a thread about this problem, in the hope to fix the respective standards. Feel free to chime in there :)