GTalk users own idea of clientId does not match what peers see

[dborkan]

If I sign into GTalk as [email protected] with these login options:

socialClient.login({
        agent: 'integration',
        version: '0.1',
        url: '',
        interactive: false,
        rememberLogin: false
      });

Bob will see that his clientId is "[email protected]/integration" (both as the argument when login's returned promise is fulfilled and in an onClientState event).

However, Bob's friend Alice will see that his clientId is "[email protected]/integratioC77E5224". We know that GTalk anonymizes the email address (JID) between some peers, but we think that both peers should agree on the same unique portion of the client id (what follows the /)

This makes it hard to write tests where we create 2 social clients and try to send messages between them (if Alice wants to send a message to Bob, we can't tell which is the Bob client we just created for our test VS which is an old Bob client). Also these modifications to the clientId after the / (removing the last 'n' in 'integration' and adding some hex) means we can't pass much data between peers as part of the clientId (it would be nice if the uProxy instanceId could be part of the clientId).

[willscott]

The resource can't be assumed to be stable to peers, per the XMPP spec: http://xmpp.org/rfcs/rfc3920.html#rfc.section.3.4

I'm not sure if there's anything that this library can do about that - we will let you know if there are remote clients online with the same app, but negotiation to maintain stable identifiers is something that the client probably needs to do.

I'd be in favor of solving this via a library layer that does public key negotiations to re-discover remote devices that have previously been trusted.

[iislucas]

cool, this is not strictly needed, but lets make sure that this documented in the social provider so that it's clear what can and cannot be assumed of the social provider. In particular, we should explicitly call out that social provider does not ensure that client-id's are stable between different user's perspective of them, likewise with user-ids, although user-ids are ensured to be consistent.