[Wocky] Flaw in reciprocal buddy-adding

[Greg Hudson]

> I assume this is a Gaim bug, but it could conceivably be a jabberd
> bug if the server is expected to provide reciprocal access.  I will
> put this on my list of things to dig into.

It's a Gaim bug.  Here's what happens:

  1. Alice adds a buddy Bob
  2. Bob receives an authorization request for Alice's subscription
  3. Bob approves the request (message sent to server)
  4. Bob's Gaim process sees that Alice is not currently a buddy, and
     displays the reciprocal buddy-adding dialog.  (Like all Gaim
     dialogs, this one is non-modal, so control returns to the main
     loop.)
  5. Bob's Gaim receives a roster push from the server containing a
     buddy entry for Alice, with a subscription type of 'From'.  Bob's
     Gaim stuffs that into the 'Buddies' group since no group is
     specified.
  6. Bob finishes filling out the reciprocal buddy-adding form, thus
     asking Gaim to add Alice to his 'Buddies' group.  (If Bob chooses
     a different group, then things actually work.)
  7. Bob's Gaim sees that Alice is already a buddy, due to the roster
     push in step 5, and does nothing.  Bob may as well have clicked
     cancel on the reciprocal buddy-adding dialog.

There is clearly an impedance mismatch between Jabber, where you can
have a buddy entry but not have requested subscription rights, and
Gaim, which was built around the simpler AIM model.  Also, it's not
clear to me that Gaim is making a wise decision by sticking ungrouped
roster entries in the 'Buddies' group.

Confusing matters, the conditional in step 7 only appears on the gaim
1.5 branch, along with a bunch of other work which never seems to have
made it to the mainline.  So Gaim 2.0 probably doesn't manifest this
bug, but might manifest other bugs instead.

I will test some candidate fixes soon, and will also try this scenario
and some related scenarios in the Gaim 2.0 beta.