[OTR-dev] finished state and restart

[Greg Troxel]

Paul Wouters <paul at cypherpunks.ca> writes:

>> (There's perhaps a minor bug in that the 'started' line should precede
>> the message, or else a serious bug that it was sent un-OTRed.)
>
> If you use "opportunistic mode", eg "on demand", then your first message
> will always be plaintext, upon which the other end sees you can do OTR
> and replies encrypted. If you want to prevent your first message from
> being plaintext, either click on OTR to start before typing, or change
> the preference for this user to "require OTR".

Thanks - I do understand that, and am pretty sure this happened with a
user for whom I have OTR settings set to require.  I just did a test
where I set someone to 'require' and then typed a test message.  I got
"Attempting to start a private conversation...", followed by my
message in the upper window (gaim 1.5).  I don't know that it was
actually sent.  This user is running a non-OTR client, so I got no
response.

I think that in the case of a negotiation triggered by 'require', that
the message should not appear in the log window until after the
notification of successful OTR negotiation.

> I have thought about these things as well. The issue is a bit more complex,
> due to multiple logins. I am not sure why we don't go to a finished state
> ourselves when the other end enters that state. If we are setup as "require"
> then no plaintext messages will ever be sent, and an OTR negotiation is
> triggered.

I didn't think about multiple logins.  But, my client did go to state
finished, and then a new message simply dropped it and notified me of
failure, rather than triggering a negotiation.

> What I'm concerned about is that certain messages can trigger a new
> negotiation, undoing the finished state.

messages from the peer, or from the user?

> btw. the point of finished is to ensure that if that user logins from
> a new location, he doesn't get unreadable messages. And that is also
> related to the oldest oustanding otr bug, the "negotiation storm" that
> seems to happen sometimes when one user has been idle for a long time,
> and perhaps logged in from somewhere else and did some otr.

Ah - of course - thanks for pointing that out.  But still, my notion
that a locally-generated message in state finished for users set to
'require' should trigger negotiation, just like it would in state 'not
private' doesn't contradict any of that.
This is really just automating hitting the negotiate button.