Fwd: [OTR-users] OTR on aim and multiple logins

[Gregory Maxwell]

Ian responded off list, and gave me permission to forward once he
realized his error.

---------- Forwarded message ----------
From: Ian Goldberg <ian at cypherpunks.ca>
Date: Mar 20, 2006 1:07 PM
Subject: Re: [OTR-users] OTR on aim and multiple logins
To: gmaxwell at gmail.com


On Mon, Mar 20, 2006 at 12:30:09PM -0500, Gregory Maxwell wrote:
> One of my only friends that I have trouble getting to use OTR is
> already a gaim user.. and a Linux user... and had no problems getting
> it installed.
>
> Instead his problem is that he leaves multiple systems logged into AIM
> on the same accounts...
>
> And OTR between his systems and mine enter into a war...
>
> Could we solve this problem like this:
>                 ---him a
> me ---[aim]
>                 ---him b
>
> Lets assume that we add a field to the protocol, a client identifier..
> every client generates a new random one per neighbor.  So I will have
> a [me->him id] and him a will have a [him->me id] and him b will have
> a distinct [him->me id].
>
> I send some OTR related message, both his clients respond. I see there
> are two responses. I send another OTR message saying 'how long since
> you last received user input'.  Both respond. I pick the most recent,
> and I direct all further messages to him and the losing client stays
> quiet because the messages are not directed to his ID.
>
> Thoughts on this?

Something like that is already in the works, as this multiple-login
thing is our biggest usability problem right now.  I think you can get
away with one random id per account per client.  I'm not sure the
explicit query for idle time will work, or that all clients would even
be able to respond to such a thing.  We do need some robust way to
figure out where to direct the messages.

I believe the AIM server's multicast algorithm is something like:

- If Bob is logged on exactly once, send the message to him.
- If he's logged on more than once, and exactly one is non-idle, send it
  to only that login.
- If he's logged on more than once, and zero, or more than one, is
  non-idle, send it to all of Bob's logins.  [Maybe this is really "all
  of Bob's non-idle logins, if more than one".]

So in your friend's case, you should only be seeing a problem once both
of his logins go idle.  But in that case, how do you know which computer
he's more likely to be sitting in front of?  If one's been idle for 2.5
hours, and one's been idle for 3 hours?  I don't think you can make a
decision based just on that information.

When a client receives a message containing an ID not its own, it should
still display *something*, so that if the user does happen to be sitting
there, he'll notice you're trying to talk to him, and click his OTR
button to restart the private conversation.  That way, if you chose
incorrectly, you're still likely to be able to recover.  Unfortunately,
that would seem to result in the "other" screen being filled with
whatever this *something* is.  I suppose it could just display something
on SIGMA messages, and not on Data messages.  Or something like that.
More thinking clearly needs to be done to make this work out.

   - Ian