Created attachment 8503663 [details] [diff] [review] raw.patch User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36
Is there a particular situation this occurs in? (Where the conversation disappears.)
If it doesn't go through the conversation service, it bypasses the observers we added for encryption.
On second thought, maybe it's better to add another notifier in the command service before executing them that the otr extension can observe and modify ... hmmm. That seem like an ok place to solve the /me /msg command issues as well.
Created attachment 8503691 [details] [diff] [review] command.patch Something like this patch. Pidgin seems to have decided on encrypting "/me ..." as a string and sending a PRIVMSG instead of an action. https://lists.cypherpunks.ca/pipermail/otr-dev/2013-September/001871.html https://lists.cypherpunks.ca/pipermail/otr-dev/2013-September/001886.html https://hg.pidgin.im/pidgin/main/rev/3edc70bf4e09 That's the "command may have changed" in the patch. Pidgin currently doesn't handle encryption for notify|msg|query. I opened https://developer.pidgin.im/ticket/16397 for them, so I suppose we can't look there to see how to do it.
I find the description is this bug to be lacking. Context is available at . Overall it's to solve how commands should be handled with OTR. /raw can be used on all protocols. IRC has /me, /msg, /notice. (In reply to arlolra from comment #4) > Pidgin seems to have decided on encrypting "/me ..." as a string and sending > a PRIVMSG instead of an action. This is a *bad* idea. Encrypting the full CTCP string should be done so you can encrypt any arbitrary CTCP command (e.g. DCC connects). This also makes it wayyyy Pidgin specific (since they parse "/me " at the front of messages to determine whether it's an action or not). I dislike this decision.  http://log.bezut.info/instantbird/141011/#m170
So we talked about this briefly on IRC, but wanted to put it in the bug too. I think both Florian and I find this bug pretty confusing. The /raw/ patch seems reasonable, can we split the other commands to separate bugs?
Sure, it's already r+'d so feel free to merge.