[OTR-dev] Re: Re: Requirements for libotr4

[Uli M]

On Thu 19.06.08 14:37, Ian Goldberg wrote:
> On Wed, Jun 18, 2008 at 10:24:23PM +0000, Uli M wrote:
- snip -
> > 1. Asynchronous key generation. On some systems key generation can
> > take more than one hour. I don't know how other IM-clients do it but I
> > had to create a seperate process (not thread) for key generation which
> > is really not ideal since inter-thread communication is a lot simpler.
> > Also key generation will just finish at some random point in time and
> > update the keys file. What I would like to have is one thread safe
> > function that generates a key (some opaque struct I don't care about)
> > which I can later on(in my main thread) give to libotr for inclusion.
> 
> OK, that's an interesting request.  I think we can do that.  Willy,
> write that down.  ;-)

great! ;)

> I don't want to put anything thready into libotr, but we can have a
> call like:
> 
> gcry_error_t otrl_privkey_generate_start(OtrlUserState us,
>     const char *accountname, const char *protocol,
>     void (*call_when_done)(void *newkey, void *data), void *data);
> 
> which (after some time) will call call_when_done with a pointer to the
> new key and whatever data you passed in.
> 
> Then there can be:
> 
> gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp);
> 
> which writes the newkey into the FILE (and frees newkey).  Your
> call_when_done routine can call that directly if you're single-threaded,
> or signal the main thread that it's ready, or whatever.
> 
> 
> What do you think of that?

That sounds good. But I'm guessing the finish() function would besides saving
the key also have to do the other duties of the old otrl_privkey_generate
function, namely updating OtrlUserState:

/* Generate a private DSA key for a given account, storing it into a
 * file on disk, and loading it into the given OtrlUserState.  Overwrite any
 * previously generated keys for that account in that OtrlUserState. */


- snip -
> > 4. The 3 line spanning OTR announce message, ironically also called
> > "better message" in the code. This is again a hardcoded string I would
> > like to see disappear. The really really bad thing about it is that it
> > is a 3 line message and in IRC we don't have newlines. So in order to
> > eat this message up and not present it to the user I had to hardcode
> > the second and third line in irssi-otr. Bad!
> 
> We want to display *something* to the other user if he doesn't have OTR
> installed, though.  Are you suggesting each IM client can provide its
> own text here?  That would be OK, I suppose.  We'd need another
> OtrlMessageUiOps callback for that.

Yes, I think it would be good if each IM-client could provide its own
text here and decide whether it's english, vietnamese, text/plain,
text/html, or image/svg+xml ;)

And should there be a default it should be text/plain and only *one*
line.  

(Personally, I'd simply use ?OTR? as the default since people can
probably guess what's going on or even more likely already talked about
using OTR now)

As I tried to explain before with the current 3 line message an IRC
client gets in fact 3 distinct messages. He gives the first received msg
to libotr containing the ?OTR? and libotr does fancy stuff with it. Then
it gives it the second and third line and libotr will just give it back
those two lines as they were, the result being that the IRC client
displays the last two lines to the user "nick at somewhere/resource wants
to do otr but you cant do it" although OTR is actually going to start in
a few seconds. The only way around this (I saw) is to hardcode line 2
and 3 and eat them when they come.

Uli