Inform for message bridging delay or failure

[opk12]

Lack of visual indication that a message was not bridged or is delayed more than ten seconds or so can lead to loss of information (or user confusion). Often, the context and the flow of mutual responses allow the safe assumption that a verbal acknowledgement is not necessary, or that lack of an answer (or only answering to one of multiple messages that were sent separately from the bridge's other side) means tacit consent / no objections. A simple message not delivered yet would be sufficient to imply to wait or use alternative communication channels.

For example, this was most apparent in our room in the last month, in the context of the recent matrix.org attacks; we then had to head to t2bot.io's support chat and find out that bridging failures and delays were widely reported. But the lack of notification of failures is still a latent issue in general, regardless of a specific outage.

[tulir]

The t2bot.io case sounds like federation delays. The bridge can't report problems with messages it hasn't received.

There's also already the delivery_receipts option to make the bridge bot send a read receipt when it has handled a message (so a lack of read receipt means message not handled)

[opk12]

Ah, that's why. I did not know about delivery_receipts and delivery_error_reports, thanks. The question becomes why they are disabled on t2bot. I also found the #637 along similar lines.