[OTR-dev] semantics of MSGSTATE_FINISHED

[Taylor R Campbell]

[I tried sending this a few days ago without subscribing to the list,
but it never showed up in the archive, so I imagine I need to be
subscribed.  If I'm mistaken, apologies for the duplicate message.]

When an OTR user receives a DISCONNECTED TLV, his message state
transitions to MSGSTATE_FINISHED.  Afterward, otrl_message_sending
will always succeed in the sense of returning an error code indicating
success, but will display a message saying `Your message was not sent.
Either end your private conversation, or restart it.'  This causes
frustration such as what is documented in Adium ticket 6600, at
<http://trac.adium.im/ticket/6600>.  I'd like to fix this.

I think that one way would be simply to omit MSGSTATE_FINISHED and to
substitute MSGSTATE_PLAINTEXT for it.  Then if the user wanted every
message to be encrypted, and requested OTRL_POLICY_REQUIRE_ENCRYPTION,
I believe that otrl_message_sending would do the right thing after a
DISCONNECTED TLV and negotiate a new OTR session.  Also, the notice
that has frustrated me and others could be done away with.  But that
might surprise users who use different policies.

If the user doesn't care that every message be encrypted, but would
not want a DISCONNECTED TLV to cause subsequent messages to be sent in
plaintext, then another way would be to apply in MSGSTATE_FINISHED the
same logic in MSGSTATE_PLAINTEXT for OTRL_POLICY_REQUIRE_ENCRYPTION.
The user would still be notified that the message could not be sent as
it was, but the OTR library would attempt to negotiate a new OTR
session, and if that failed (e.g., because the other user actually did
simply go offline), then the user would be notified of the reason why
the software really could not transmit the message to the other user.

At the very least, it would be nice if otrl_message_sending returned
an error code indicating failure whenever it failed to send a message,
such as when in the MSGSTATE_FINISHED state.  Right now, clients think
that OTR succeeded and proceed as if it had.  Adium echoes the message
just like any message it has successfully sent, and puts the notice
about `Your message was not sent' in a very innocuous place that I
often don't see until much later.  Nowhere does it indicate any reason
why the message was not sent, either -- almost as though it just got
lazy and didn't feel like sending the message I asked it to send!

Am I missing something about the OTR protocol, or do any of these
ideas sound plausible modifications to the protocol to prevent the
incredibly frustrating behaviour that it currently causes?  Please let
me know if you'd like patches -- I have not tested any of these ideas,
but I'd be happy to do so and send patches.