Nice Handling for "broken" Messages

[allo-]

At the moment, yaxim displays a lot of gibberish, when a borken client sends a OTR-Request, even when yaxim does not support it, yet.
Further there are other encryption plugins, i.e. with PGP, which will send unreadable text, too.

It would be good to keep as much as possible of this problems away from the enduser and maybe inform the sender with some kind of autoreply, or "OTR not supported/End OTR session" message (i do not know the details of the protocol).

This is a workaround, as the problem is the sender, but a enduser does not care about the cause, only about the experience. So it would be good to work around those issues, while they are not fixed in other clients.

[martin-steghoefer]

Just to stress the importance of this bug report: IMO this is more than just a workaround to deal with broken clients at the other end of the line. This also happens, if you use Message Carbons (XEP-0280) and OTR at the same time. Yaxim will display all those carbon-copies of the encrypted messages sent/received by your OTR-capable client as raw OTR, which messes up the chat log. I suggest to filter those messages.

[ge0rg]

Sorry, but this is still about broken clients at the other end. XEP-0280 section 9 outlines how to prevent carbons of individual messages, and an OTR-implementing client should set that flag on OTR messages so they are not reflected to other clients.

Even if we consider "fixing" this in yaxim, I'm not sure what would make a good UX:

• Just replace each broken message with the string "OTR garbage" (or some other i18nized string)? --> Your log is still getting full with garbage.
• Unify consecutive "OTR garbage" messages into one, to not clutter the log? --> Complex implementation.
• Comepletely ignore OTR garbage messages? --> That would break the UX for the other person, writing you something and expecting an answer.

[martin-steghoefer]

Sorry, but this is still about broken clients at the other end. XEP-0280 section 9 outlines how to prevent carbons of individual messages, and an OTR-implementing client should set that flag on OTR messages so they are not reflected to other clients.

Yes, that's the clean solution for XEP-0280-aware clients. But you cannot require every OTR-implementing client to support XEP-0280. Clients like that are not at all "broken": They properly implement the XMPP and OTR protocols - XEP-0280 is optional.

But I agree that it isn't yaxim's "fault". It's just a protocol weakness due to OTR not being integrated with XMPP. But since the protocols are something that we just have to deal with, I still think that it's a good idea to work around this problem by filtering messages.

Option 1: Just replace each broken message with the string "OTR garbage" (or some other i18nized string)? --> Your log is still getting full with garbage.

True, that wouldn't help much. It would be a slightly improved UX because the user is told what is happening, but the log will still be cluttered.

Option 2: Unify consecutive "OTR garbage" messages into one, to not clutter the log? --> Complex implementation.

If just a generic message like "OTR garbage" is displayed, then you will have the same problem as with Option 3: If you forget to close the OTR session, the other user sends you a message that never gets your attention. To avoid this, you would need a message like "17 unreadable OTR messages received between 10:17:03 and 10:28:19" that is updated every time you receive an OTR message.

I'm not familiar with yaxim's architectur, so I cannot comment on the implementation complexity. But I think this would make the best user experience.

Option 3: Comepletely ignore OTR garbage messages? --> That would break the UX for the other person, writing you something and expecting an answer.

Being able to communicate with exactly one client at the other end of the line, that's in the nature of end-to-end encryption. So I don't see a big surprise for the user here. Fully seamless client switching cannot be expected when using end-to-end encryption. If you close the OTR session like you're supposed to, there's no problem.

But, of course, users aren't infallible. So seeing the fact that there are incoming OTR messages in case of having failed to close the OTR session on your other client would be nicer.

There might also be a fourth option: Many clients treat their log differently than the currently open sessions. There are additional control messages ("Linus Torvalds just changed his status from 'Available' to 'Away'." or "OTR session started.") that are useful for the current session, but don't need to be archived in the chat log. There also normal message that aren't logged under certain conditions (e.g. when using OTR). Our warnings about having received unreadable encrypted messages could treated like that. This way the message receives the user's attention (avoiding the problem you point out with option 3), but doesn't clutter the log. Since the unification of several of those messages isn't crucial with this option, it might be easier to implement than Option 2 - provided that the concept of meta messages or the concept of session vs. log exists in the yaxim architecture.

[ge0rg]

Okay, I'm implementing a half-solution in 9d4d3c3. Carbons of OTR messages will be silently discarded by yaxim, to compensate for broken clients. If yaxim is receiving an OTR message routed at it's full JID, it will be displayed as garbage though.

This way I hope to not cause a situation where yaxim is responsible for the message and fails to show it to the user.