[OTR-dev] Secure connections through a connect/disconnect cycle, OTR error messages
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
> 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
>> Didn't you say in another thread that there should be no automatic
>> disconnection of the ConnContext when signing off? So the
>> 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.
>> 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).
> 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 ;)
More information about the OTR-dev