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

Ian Goldberg ian at cypherpunks.ca
Thu Jun 7 18:39:54 EDT 2007

On Thu, Jun 07, 2007 at 02:06:21PM +0200, Rüdiger Kuhlmann wrote:
> Hi everyone,
> 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:
> * 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
OTRL_MSGSTATE_FINISHED; context->active_fingerprint->trust tells you the
trust level (if you're in OTRL_MSGSTATE_ENCRYPTED).

> * For outgoing messages, it is impossible to know whether the encrypted
>   message contains the original message or is just initiating the OTR
>   handshake (which makes it impossible to properly follow up with
>   acknowledgements of the IM system), because...
> * ... the library is unable to signal back that the message must not be
>   sent, or must not be sent now because no OTR session is established.
>   Resending messages is _NOT_ the task of the library!

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.

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

> * The library sends back complete sentences to the library user in a
>   language that in most cases won't be the user's language. What for
>   a crazy idea is this? The question is not, how to translate those
>   messages, the question is why send those messages at all instead
>   of sending proper error messages?? Creating appropriate error
>   messages to the user is a task of the application, not of the
>   library!
> * ... and even worse: these messages are HTML. OMG, Ponies!

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.

> * 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"?  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.  If it gets an
untagged plaintext message, it'll warn the user that the message was
received in the clear.  It can't start OTR in that case, since the
reason it received plaintext might be that your buddy switched to a
non-OTR-capable client.

> By the way, this email answers the question on the list for a command line
> otr application with "now there is one" (doing ICQ and XMPP).

Excellent!  I've made a note of it on the OTR homepage.

   - Ian

More information about the OTR-dev mailing list