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

Evan Schoenberg evan.s at dreskin.net
Thu Jan 27 17:20:33 EST 2005


On Jan 27, 2005, at 4:06 PM, Ian Goldberg wrote:
>
> 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.
>
Which is a situation that I've been saying in several different threads 
should change.  That's not the only way to deliver inline messages.  
For a client which can only display an inline message as an incoming 
message, it can implement the inform_error callback to simply call the 
inform_message callback.  For a client which can differentiate and 
still be inline... such as Gaim and Adium... it can provide a better 
user experience by having the chance to handle the inline error 
differently.

> 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.

> <snip>
>> And on another tack: Does the heartbeat present the same problem?
>
> The first attempt had this very problem.   <snip>
Hm.  Okay, what if the UI had a callback which could let the library 
know if the user is available for heartbeats and conversation closed 
messages?  If the information is unavailable, the UI just returns NO, 
and we proceed as we do at present... but if the information is 
available (in Gaim, it's an easy check to find out if a given 
username/account/protocol combination is available, and in Adium 
similarly) then we can do the better behavior without running into the 
problem of sending messages to offline contacts.


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

> 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.
>
I'm sending an email in another thread regarding the autostarting back 
up, as I don't want to crowd this one's continuity such as it is for 
those of us using threaded mail readers ;)

-Evan




More information about the OTR-dev mailing list