[OTR-dev] 'manual' + whitespace start ake?

[Scott Ellis]

Thanks Evan...but I tried it, and get a 'duplicate case' error in one of my
switch statements...

It turns out to be because 'send whitespace tag' and 'whitespace start ake'
are both defined to be 0x08 - so they're actually both the same thing. This
means, if I define manual the way you suggest, it is exactly the same as
opportunistic - which is not what I want.

So I guess the behaviour I'm after is not possible with the current source.


On 22/02/06, Evan Schoenberg <evan.s at dreskin.net> wrote:
>
> Scott,
>
> You've come to the exact same conclusion I did with the same rationale.
> Adium's "manual" mode is actually defined as:
> /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic
> attempts at encryption.
>  * If either user has OTR set to Automatic, an OTR session should be
> begun; without this modified
>  * mask, both users would have to be on automatic for OTR to begin
> automatically, even though one user
>  * _manually_ attempting OTR will _automatically_ bring the other into OTR
> even if the setting is Manual.
>  */
> #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL |
> \
>   OTRL_POLICY_WHITESPACE_START_AKE | \
>   OTRL_POLICY_ERROR_START_AKE )
>
>
> -Evan
> www.adiumx.com
>
>  On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote:
>
>  i'm wondering, what would be the effect of adding the
> WHITESPACE_START_AKE flag into the MANUAL mode?
>
> i mean - in my testing it seems that opportunistic mode only starts OTR
> when both sides have it set - if one side is set to manual, then automatic
> initialisation of OTR does not occur.
>
> if both sides are in manual, user 1 can 'force' user 2 to start OTR...so,
> if a user chooses 'opportunistic', wouldn't it make sense to force users
> they talk to who are in manual mode to start OTR also? would adding that
> flag have that effect?
>
> Scott
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20060222/e49b4e2a/attachment.html>