[otr-dev] Creating a libotr.so ...

[Rüdiger Kuhlmann]

>--[Ian Goldberg]--<ian at cypherpunks.ca>
> On Thu, Jun 07, 2007 at 02:06:21PM +0200, Rüdiger Kuhlmann wrote:

> > * For outgoing and incoming messages, the message text may be replaced
> >   by a different text. However, the crucial information whether the
> >   message will now be sent encrypted and whether the fingerprint is
> >   trusted or not, is simply not available (and impossible to obtain
> >   correctly in all cases).
> Isn't that information in the ConnContext?  context->msgstate tells you
> whether you're in OTRL_MSGSTATE_PLAINTEXT, OTRL_MSGSTATE_ENCRYPTED, or
> OTRL_MSGSTATE_FINISHED; context->active_fingerprint->trust tells you the
> trust level (if you're in OTRL_MSGSTATE_ENCRYPTED).

Sort of. It requires that you fetch the context first :) Nevertheless, due
to the fact that the library resends messages, it is not always accurate.
Example: policy = always, send the first message. When the message is passed
on to the library, the context will indicate plain text, but the message
will, in fact, be re-sent encrypted.

So can we please please make the library stop resending stuff and leave it
up to the application?

> I agree that the otrl_message_* routines blur the line between library
> stuff and app stuff.  That's where the English HTML messages all live,
> for example.  The reason we moved them from gaim-otr to libotr is that
> we thought they may be useful to other apps.  But I totally agree that
> some refactoring may be useful there.

Fine.

> > * It is impossible to signal back to the library that an injected
> >   message could not be sent due to size constraints. Thus, the library
> >   does not provide for outgoing fragmentation at all!
> As Paul said, RSN.

Well, I'm not using cvs - I can't expect people to have dev versions
installed for dlopen to grab.

> Yes, see above.  For now, you'd probably just have to replicate the
> functionality of the otrl_message_* routines if what those routines give
> you as is isn't suitable.

Actually I hoped libotr would be fixed so that I wouldn't have to
duplicate work.

> > * If an unencrypted message with on OTR offer is received, the library
> >   does _not_ re-negotiate an OTR session (this can happen if an OTR
> >   session was established and the sending application is killed and
> >   restarted and thus doesn't know anything about any existing OTR session).
> Do you mean "an OTR offer" or "no OTR offer"?

an offer.

> If otrl_message_receiving
> gets an OTR Query message, it will start key negotiation.  If it gets a
> plaintext message with the whitespace tag, and your policy is set to
> reply to whitespace tags, it'll start key negotiation.

I managed Kopete to display me an HTML message complaining about a
plain text that visibly contained an OTR offer tag.

> If it gets an
> untagged plaintext message, it'll warn the user that the message was
> received in the clear.

Why doesn't it return appropriate flags instead of breaking the message
flow and wrapping it in HTML? When using the "try" policy it definately
isn't an error.

Also, the library displays the OTR-encoded message to the user if it gets an
otr start message, but the user has the policy never for that particular
contact. Outch.

>--[Evan Schoenberg]--<evan.s at dreskin.net>
> On Jun 7, 2007, at 6:39 PM, Ian Goldberg wrote:
> >I agree that the otrl_message_* routines blur the line between library
> >stuff and app stuff.  That's where the English HTML messages all live,
> >for example.  The reason we moved them from gaim-otr to libotr is that
> >we thought they may be useful to other apps.  But I totally agree that
> >some refactoring may be useful there.
> Optimally, these messages would be available in the library but not  
> in their current form.  It'd be awesome if the library passed back  
> defined error codes which could then, at the application's  
> discretion, either be used to generate its own messages or passed to  
> something like
> const char *otr_get_error(otr_error errno)

That would be a start.

>--[Scott Ellis]--<mail at scottellis.com.au>
> >Excellent!  I've made a note of it on the OTR homepage.
> Still no mention of the miranda plugin? :(

Btw, the Miranda plugin has a severe usability problem - it is impossible to
copy a fingerprint out of the ever-blocking popup window. How can you
compare fingerprints, when you have to write them down manually??

>--[Donny Viszneki]--<donny.viszneki at gmail.com>
> On 6/7/07, Rüdiger Kuhlmann <l-otr.0705+23jv-l at ruediger-kuhlmann.de> wrote:
> >recently I got OTR support for my instant messaging application (mICQ) by
> >using the library that should better be called libgaimotr. I found the API
> >it provides rather lacking, for the following reasons:
> I think you may have misunderstood the purpose of gaim-otr. Gaim-otr
> is not called libgaimotr because it isn't a library in casual
> parlance.

I think that reading all list message before answering would have saved you
the time to write this email... My overall complaint is that libotr is so
Gaim-specific that it is not really a general purpose library.

-- 
"See, free nations are peaceful nations. Free nations don't attack
 each other. Free nations don't develop weapons of mass destruction."
      - George W. Bush, Milwaukee, Wis., Oct. 3, 2003