[OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals

[Etan Reisner]

On Fri, 17 Feb 2006, Evan Schoenberg wrote:
> (Please reply-to-all, as I'm sending this to both relevant lists)
>
> AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any 
> other gaim plugin-based encryption scheme.
>
> 1) User sends message in Gaim
> 2) Gaim gives plugins an opportunity to modify the message; an encryption 
> plugin such as gaim-otr encrypts the message if appropriate, returning the 
> encrypted message
> 3) Gaim sends the encrypted message to the prpl
> 4) In the case of oscar within a DirectIM session, the message is normally 
> post-processed, looking for <IMG> tags, which reference ids from the gaim img 
> store in the form <img='2'> where gaim_imgstore_get(2) will return the 
> GaimStoredImage* for the image.  The image's data, size, etc. are inserted 
> into the message..... but the message is encoded, so such a tag isn't found, 
> and images can not be sent.
>
> A similar situation exists on the receiving side, where the prpl processes 
> the incoming message, looking for <img> tags to convert to the gaim img store 
> and their corresponding IDs but sees only the gibberish of an encrypted 
> message.
>
> As I mentioned, this is not specific to the gaim-otr implementation but 
> rather a result of how the signals are set up.  One solution I've come up 
> with is giving the prpl a chance to modify the outgoing message before it is 
> sent to plugins via a signal, and similarly call the prpl for final 
> post-processing of incoming messages after the first signal is sent when 
> receiving a message.
>
> Thoughts?
>
> Cheers,
> Evan
> www.adiumx.com

I only partly understand the issue here, and I have next to know 
undertanding of the underlying encryption stuff, but couldn't a prpl 
that needs to do this processing just use the same signals that the 
encryption plugins use? And use the signal priority stuff to ensure that 
they come first, to facilitate this we can change the handful of 
GAIM_PRIORITY defines to be an enum with default levels for 
PRPL/ENCRYPTION/etc. Would that not solve at least some of the problems? 
Or is there something I'm missing? Does the prpl processing do funny 
things to the message that the plugins would have to know about to deal 
with or something? Would the prpls need to keep track of messages 
between the signal and the normal mechanism somehow? (Would we need to 
start tagging messages with per-conversation ids to make this work more 
easily?)

 	-Etan