[OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message

[Scott Ellis]

On 23/02/06, Ian Goldberg <ian at cypherpunks.ca> wrote:
>
> On Thu, Feb 23, 2006 at 11:16:02AM +1100, Scott Ellis wrote:
> > > Wow.  That *is* a hack.  Surely there's a way to extract your account
> > > name, though?
> >
> > There really isn't the concept of an account name in miranda...I can get
> the
> > protocol name, or the protocol unique identifier (e.g. UIN) which may
> not be
> > human readable...or, which is about the closest thing, the name of the
> > user's database file - but that is often 'default' or something like
> that.
>
> In what protocols is the "unique identifier" not human-readable?  Is
> this not the string that someone else would type in to their IM client
> in order to send you a message?  If not, I'd think there's got to be a
> way to determine what that string is.


e.g ICQ - the UIN is just a number - readable but not meaningful to me. The
nickname they're given on the receiving end (if any) is not necessarily
known to the sender

> I guess what I'm suggesting is that the library do some processing of the
> > query message even when the policy is 'never'.
> >
> > Sorry, I mean't the username is passed into the 'receieve' function, on
> the
> > receiver side - i misunderstood your last post regarding that.
>
> Ah, but that message (generated by the sender) needs to be readable and
> make sense to someone that really *doesn't* have an OTR plugin.  So you
> can't rely on the receiver to fill in the sender's name properly.


yes I realise that - but it's prefixed with the ?OTR? thing - so if there
does happen to be an otr plugin on the receiving end, and if the message had
some sort of recognisable standard content (e.g. i've modified the lib to
remove html tags, so straight strcmp wouldn't work) then the receiver could
do something more useful with it - and also fill in the nickname of the
sender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20060223/afca6991/attachment.html>