[OTR-dev] OTR encryption state

[Ian Goldberg]

[Side note: libotr now can have separate UserStates (instead of the
static context_root and privkey_root).  It also will reencrypt and
retransmit the last message it sent encrypted (if it's very recent)
in the event that the other guy lost his OTR state. (Paul's been
requesting that since the dawn of time.)]

On Wed, Jan 26, 2005 at 01:21:15PM -0800, verbal wrote:
> that sounds reasonable. we should identify the most common usage
> scenario and set that as the default. also, i would like to change the
> first one and reword the third one.
> 
> 1) manual OTR messaging
> 2) OTR whenever possible messaging.
> 3) OTR only messaging.
> 
> so while my first mode and yours is different, with the three
> combined, they will have the same functionality. i think the
> difference between our wording for mode 1 will just end up being UI
> semantics. maybe we should get some UI people to weigh in on this.

Implementation-wise, what do you think of adding a callback that looks
something like:

OtrlMessagePolicy determine_policy(userstate, accountname, protocol,
				    username, context);

which returns information about what OTR features should and should not
be enabled for this context?

    NEVER:  Pretend OTR isn't enabled at all for this user
    ALWAYS: It is an error to send unencrypted data to this user.
            If you try, you'll get a notify(ERROR) callback and
	    the message to be sent will be turned into an OTR Error
	    message that the other side will see.
    OPPORTUNISTIC: (the current mode) probe the other side with the
                   whitespace tag, and reply to any indication that he
		   speaks OTR with a Key Exchange Message (if we're not
		   already private)
    MANUAL: Don't send the whitespace tag, and don't reply to one you
            receive.  Respond to explicit OTR Query Messages and Key Exchange
	    Messages, but not other indications of OTR.  This mode is
	    useful if you for some reason want to communicate in the
	    clear, even though you know the other guy speaks OTR, and
	    also allow either side to start a private conversation
	    at any time.  [If you don't want to allow that last
	    condition, use NEVER instead.]

   - Ian