[OTR-dev] Re: Requirements for libotr4

[Ian Goldberg]

On Wed, Jun 18, 2008 at 10:24:23PM +0000, Uli M wrote:
> Hi,
> 
> On 2008-06-18, Willy Lew
> <willylew at gmail.com> wrote:
> > ------=_Part_3121_10507133.1213753314536
> > Content-Type: text/plain; charset=ISO-8859-1
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > Hello fellow IM devs,
> >
> > As some of you may already know, we are revamping the libotr API (the
> > messaging part in particular) to address several issues that were brought up
> > recently. The four major changes are:
> 
> I'd like to mention some things I wished for when implementing
> irssi-otr (irssi is an IRC client often used in conjunction with the
> IM-to-IRC-gateway bitlbee). I believe all those points are also
> interesting for other IM-clients.
> 
> 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.  ;-)

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?

> 2. No hardcoded strings at all. I don't know if your point about error
> codes covers the case "The following message ... was not encrypted:
> [...]". Here one would need an error code plus the message that was
> received.
> 
> 3. [resent] messages. They should be handled in the same way as the
> msgs I mentioned in 2., OTR shouldnt change messages at all and most
> certainly not inject a hardcoded "[resent]" string.

Agreed on both counts.  The appropriate handler routine will in fact
need to take some extra params, as you point out.

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

> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see
> disappear. Because of it, it is impossible to transfer OTR
> conversations over OTR...and also complicated to talk about OTR in an
> OTR session...I always find myself writing "if you wanna restart OTR
> write <question mark>OTR....". A function otr_restart would be the
> right thing here I believe.

I'll address this downthread.

> 6. SMP handling. Ian said this would be reworked but it's missing in
> the 4 points below. E.g. applications really shouldnt mess around with
> variables that libotr touches as well (smstate->nextExpected).

Oh, right.  Yes, this will also be cleaned up.

> 7. Maximum message size handshake. Currently, each end uses its own
> MMS. This is a bad thing if you use something like jabber transports
> because the jabber end will likely have a too large MMS for the other
> end (ICQ,...). For irssi-otr it's always a problem in conjunction with
> bitlbee since IRC has a limit of about 500 and the other end might be
> playing with 2k. The only reason why this currently works at all is
> because OTR messages (except the 'better' msg under 4.) start with
> "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr.
> The solution is simple: Each end advertises its own MSS during the
> initial handshake and both use the minimum of the two.

Downthread as well.

   - Ian