[OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages

Ian Goldberg ian at cypherpunks.ca
Thu Jan 27 17:06:23 EST 2005


On Thu, Jan 27, 2005 at 03:28:03PM -0600, Evan Schoenberg wrote:
> >But I still think the client should send that message, not libotr.  You
> >*don't* want the library to have to guess whether people you've got a
> >context with are actually still online, since having the library send a
> >message to an offline person causes no end of trouble.
> 
> Except then it has to show up as a message from the person.  If I click 
> a button, my IM client should NEVER send text to the person with whom 
> I'm chatting which looks as if I have typed it.  I want it to be able 
> to show up inline but like other status changes/conversation 
> errors/conversation updates/etc.

But it *is* a message that's sent as if you typed it, whether the UI or
libotr does it.  Every (inline) message from OTR looks as if the other
user typed it, since that's the only way to deliver inline messages.

The way I'm thinking of it, that button is just a macro for typing
"[closing private connection]" (and then forgetting the state, the way
it does now).  It's perfectly acceptable (securitywise) for the user to
just type that himself, and is in fact the only real to do it currently.

> Didn't you say in another thread that there should be no automatic 
> disconnection of the ConnContext when signing off?  So the notification 
> wouldn't go out when the person signs off.

Right.  But then if *I* go non-private, it'll try to send the "Ian has
closed the private connection" message to a user who isn't there
anymore, and Nothing Good comes of that.

Also, ConnContexts do get disconnected if the user quits the client (or
otherwise unloads the OTR plugin).

> And on another tack: Does the heartbeat present the same problem?

The first attempt had this very problem.  Now, heartbeats are only sent
in immediate response to messages received, so you have a pretty good
chance the other guy is logged in.  But we can't make that claim in this
case, since an arbitrary time may have passed since the last time we saw
him.

Really, the user is the only one who "knows" if he's in an active
conversation, or if the window is idle.  If it's idle, there's no harm
in not sending the message.  But if the user knows that his
correspondent has just gone to do dishes or something, but it still
"there", he may want to tell him that OTR is stopping.  [Though I can't
think of a good reason why he'd want to stop it in that circumstance.]

I'm perfectly happy with just saying the user can let the other guy know
he's planning to stop OTR if he wants to.

Note that once the "policy" stuff goes in, the user can switch to
"MANUAL" state, so that the other guy's typing doesn't cause OTR to
auto-start back up.

   - Ian



More information about the OTR-dev mailing list