[CCing the list again...] segler_alex wrote: > hmmm, but this sounds not very user friendly to configure. > is this possible from an "Client.Observer" point of view?
That's another way to do it. You could also do it by making the CMs smart enough to recognize that OTR is going on, and indicate this somehow on the Messages interface. Or, you could make the CMs do all the OTR for you, with API that could work for OTR or XTLS, whichever is available. We discussed this briefly on #telepathy; I attach the log. -- Will
danni | wjt: instead of writing a proxy CM
danni | could you abuse observers ?
wjt | well... maybe.
wjt | the problem is for channel requests:
wjt | » address book requests a channel
wjt | » magic OTR observer steals it
wjt | » address book is told the request succeeded
wjt | » new OTR proxy channel pops up
wjt | » gets dispatched normally
wjt | If the text handler supports AddRequest, it'll get the first request,
and then it'll go away, and then it'll get a channel
wjt | it could probably work...
sjoerd | and your logger will log both bullshit and otr messages ;)
danni | your channel is plugged into the observer, and which then creates a
new channel itself
wjt | sjoerd: this would be a reason for tiered observers
danni | wjt: maybe the CD needs an extra class? Modulators
sjoerd | wjt: that doesn't really solve it as the logger should be the lowest
tier
danni | which can futz with channel contents
wjt | right
danni | of course, at this point you pass the bong along
danni | because once people have a modulator plugged in that's modulating
_all_ text channels indiscriminately
danni | we'll run into the world of MY TELEPATHY DOESN'T WORK WITH YOURS
danni | (OMG THIS SOFTWARE IS SHIT)
! sjoerd doesn't think the solution in this case should be, add even
more moving parts ;)
danni | all because they install telepathy-otr-plugin, which has installed
some crack into the CD
danni | sjoerd: I agree, more spec seems wrong
danni | I guess I was just wondering about abusing existing spec, for evil
wjt | well, we'll need *some* extra spec for XTLS
sjoerd | i'm still somewhat convince you could do otr mostly outside of cms
insid the cm by using the messages interface
sjoerd | but yeah, the encrypted channel spec should be good enough to cope
with both something like otr and xtls
danni | could you do OTR as a mime type within the messages spec?
sjoerd | danni: that's what i'm suggesting indeed
wjt | right, you could make an OTR message type, and then your UI would deal
with it
danni | application/octet+ssl+html
wjt | yes, this means Empathy, Kopete, and your other favourite text UI
would have to grow OTR support
wjt | but you're going to need *some* UI for it
danni | yeah, it's not very Telepathy-esque
danni | to require this support in the apps though
sjoerd | hence the second suggestion to at least keep otr in mind when we
design the encrypted channels spec
sjoerd | on xmpp, i'd really prefer us using xtls as that gives us much more
flexibility
danni | also because it's not nutty?
sjoerd | other cms (say butterfly) could do otr instead assuming MSN doesn't
have a proper e2e encryption mechanism
danni | who seriously uses MSN between two users who have a client supporting
OTR ?
wjt | lots and LOTS of people
wjt | Everyone who uses Adium on the Mac
sjoerd | danni: people using adium or pidgin or whatever, but use msn as their
main protocol
istaz | sjoerd: wouldn't you need some UI anyway to configure the OIM stuff?
(encryption keys?)
sjoerd | istaz: we need that both for xtls and otr
signature.asc
Description: OpenPGP digital signature
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
