Automatically end session when other person ends

[olabini]

See https://bugs.otr.im/plugins/pidgin-otr/issues/124

[claucece]

Unsure, when this happened, but now the 'End private conversation button' is not being active.

[claucece]

Right now, in the path I could test, we show to both sides: 'private conversation lost'.

[olabini]

Showing "private conversation lost" is not the right user experience in this case. It should say something better.

[claucece]

Agreed @olabini . I'll also send an email to Ian asking why in the past this was shown:
X has ended his/her private conversation with you; you should do the same.

[claucece]

The reason for having this behavior if that:

In previous OTR versions, receiving a disconnected TLV would put the
state machine into a "FINISHED" state. A client in this state would
refuse to send new messages from the user until the user explicitly
indicated that they understood the conversation was over.

The rationale was to prevent the following scenario:
- Alice's client sends a disconnected TLV to Bob's client
- Bob types a secret message into his client's textbox and begins to move his hand toward the "send" button
- Bob's client receives the disconnected TLV and enters an "unencrypted" state
- Bob presses the "send" button
- Bob's client sends an unencrypted message that Bob intended to be sent securely

Previous OTR clients handled this situation by refusing to send Bob's message until he indicated that he understood the encrypted conversation was over, and then re-sent the message (or not). There are other UX choices that can be made here, but they must prevent this accidental leakage scenario.

We can do this:

1. Show a warning that the message will be sent unencrypted
2. Change the send button to a warning
3. Refuse to send after some x time, in which the user is shown that the message will be sent unencypted.

[pedropalau]

This is very nice. @claucece what do you think about the following steps:

1. Block the possibility to send new messages showing the user that the current status of the conversation is now Not private.
2. Disable the Send button.
3. If the user want to send new messages without encryption, give him the possibility to start a normal conversation.

About the first step, I prefer to block the sending of the message instead of sending it without encryption, because if the user was previously in a Private conversation, I think was because of the security properties of the protocol.

I don't know until what point could be tricky the fact to send the message without encryption and only show him a warning message.