<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">That would be kind of a pain, but if you really want to fix it I guess that's</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">the only way to do it.<SPAN class="Apple-converted-space"> </SPAN>Personally I'd rather see us implement AIM's built-in</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">encryption capabilities.<SPAN class="Apple-converted-space"> </SPAN>That wouldn't solve the problem, but it would</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">hopefully make it less of an issue?</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>Eh, from what I've heard, AIM's built-in encryption is nothing to write home about nor possibly even to write gaim-devl about. IANAC, though. Either way, even if we implement AIM's solution, that doesn't mean that (a) people won't still want to use the less-configuration, documented-protocol, etc. OTR solution, (b) other, similar solutions won't come up in the future, and (c) Sametime and any other prpl that needs pre/post prpl-level message processing will be fixed.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It may be some time before I have a chance to fix it, so if someone else wants to work on it feel free -- but I'll look into a clean, minimally invasive solution in the not too distant future.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-Evan</DIV></BODY></HTML>