[OTR-dev] daemon-only?

[Alex Black]

> It can't be quite this simple, because there has to be a means to  
> defend against the possible MITM attack.  Also, there are  
> circumstances when one can legitimately generate more than one key.  
> As a UI designer, you have to consider how to minimize confusion for  
> the users in those situations.

generate more than one key = single command. do you mean more than one  
key for an individual username? never had cause to do it. would those  
keys be used for specific recipients?

> There also have to be mechanisms to indicate when a session is  
> private and when it is exposed.

Is it insane to have OTR announced in the chat session (proxy  
masquerading as the other user)? would certainly be in context..

>> Much of what I see in the UI is an attempt to deal with these  
>> issues I've outlined above.  That doesn't necessarily mean I think  
>> think it's a well-executed design. ;-)

ok:

keygen can be handled either with a simple commandline app or with a  
slightly fancier standalone ui, though I don't see the point given the  
audience for an OTR proxy ;) I think most can, at minimum, get to a  
terminal and execute a command.

which leaves announcing the session is encrypted or in the clear and  
soliciting user approval for the acceptance of keys. the former can be  
a matter of preference: "I don't care / don't tell me" "announce the  
status whenever it changes" or "announce only when encryption is being  
used". the latter can I think be effectively handled by a simple  
dialog. even something fancy that fades up ;)

best,

_alex


--
alex black
founder, turing
510 666 0074
enigma at turingstudio.com