[Telepathy] Gabble avatars

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 19 Oct 2006 at 16:07:32 +0100, Dafydd Harries wrote:
> Ar 19/10/2006 am 14:43, ysgrifennodd Simon McVittie:
> > On Sun, 15 Oct 2006 at 03:47:07 +0100, Dafydd Harries wrote:
> > >  - GetAvatarTokens([self_handle]) -> [""] :(
> > 
> > Works now. On connection to the server, the vCard manager fetches our
> > own vCard (and sometimes edits it to include a better alias) - it now
> > emits got-self-initial-avatar, which is received by the GabbleConnection
> > and used to put our own avatar token in the presence cache.
> 
> Can you clarify what happens if GetAvatarTokens gets called before we receive
> our own vCard? My intention was that the D-Bus method context would get saved
> and that we would make it return when we get the vCard back. There is a corner
> case where the D-Bus method can time out if it's less than the vCard timeout
> though.

At the moment GetAvatarTokens returns "", same as if we don't have
any presence yet for one of the other contacts. I can change it, though;
since we kick off the vCard request immediately anyway, GetAvatarTokens
should probably block til that returns.

We currently allow 20 seconds for the vCard download; I think D-Bus
defaults to 30? So we should be OK. Worst case, the D-Bus method times
out and the client tries again later, wasting some bus bandwidth.

> This is a similar problem to that of trying to call somebody as soon as you go
> online: if you try right away, you probably won't have presence for them. The
> difference is that you can wait for CapabilitiesChanged on that person and
> time out on that; there's no way to know when it's safe to try and call
> GetAvatarTokens on the self handle.
> 
> > Non-XEP-0153 clients
> > ====================
> > 
> > If a non-XEP-0153 client (e.g. an older Gabble) is also logged in on our
> > account, we have to stop advertising the avatar [...]
> 
> How do we know whether clients signed on on our other resources are compliant?

Compliant clients always say <x xmlns="vcard-temp:x:update"> in their
presence, non-compliant clients never do.

Compliant client with a photo:
   <presence>...<x xmlns="vcard-temp:x:update"><photo>...</photo></x></presence>
Compliant client with no photo:
   <presence>...<x xmlns="vcard-temp:x:update"><photo></photo></x></presence>
Compliant client currently unable to say whether it has a photo or not:
   <presence>...<x xmlns="vcard-temp:x:update"></x></presence>

> Note that we don't necessarily know when one of our other resources changes
> the vCard anyway, as the XEP 0153 only provides for notification of changes to
> the avatar.

The point is that if a compliant resource changes the vCard, we're told
about it in presence. When there are non-compliant resources around, we
lack that guarantee.

Rob McQueen recommends violating this part of the XEP too, and just assuming
that any non-XEP-0153 clients won't touch the PHOTO. This is a simple
thing to do, and should be basically OK, as long as Gabble is robust
against the following case:

* We tell the Telepathy UI our own avatar has SHA-1 aaaa
* The other, non-compliant, client quietly changes the PHOTO to one
  whose SHA-1 is bbbb
* The UI calls RequestAvatar(self_handle, "aaaa")

which I'm going to handle by making RequestAvatar() fail, more or less
simultaneously emitting AvatarUpdated with token bbbb, and starting to
include bbbb in the advertised presence from then on.

> > I assume this is to defend against clients which calculate a wrong SHA-1?
> > 
> > At the moment I just trust that Gajim (or whatever) has got its sha1
> > calculation right, and start advertising that sha1 immediately. This is
> > technically a XEP violation.
> 
> Perhaps worth bringing up on the Standards-JIG or jdev mailing list.

... or not, since this is a historical spec.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFFN51hWSc8zVUw7HYRAmNiAKCwjOZ0Z6uWGeJHFcU9FoTrREtxKwCbBG/3
s2r0NZjmYwsAyqyxDH2DbUs=
=snqB
-----END PGP SIGNATURE-----