-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/14/09 3:42 AM, Remko Tronçon wrote: >> Openfire allows this, and the gateways use jabber:iq:roster. It works >> fine, but in order to use too roster sequencing I'd like to have a >> centralized repository of the roster, and the best approach, if we >> don't want to hack into the server, is to directly tell the client >> what to do. > > Openfire lets the components use jabber:iq:roster on a user's roster, > but that involves quite a bit of trust on the component (as it has > access to the full roster). > > I meant something different: > - The client logs in > - It gets presence from "gateway.example.com", which includes the > "shared-roster" capability > - It does a jabber:iq:roster request on gateway.example.com > - It adds the resulting items to the *displayed* roster (not the master > roster) > - The gateway acts as a real server from now on: it sends presence, > subscription requests, and roster pushes for all contacts in its > roster to the client that requested the roster, and forwards presence > to all contacts in the reverse direction.
This is not limited to gateways, but also to shared groups services (e.g., you get all the XSF members in a special "Members" group). I agree that it would be better to have two different protocols: one for sharing roster items with friends (preferably also coupled with the ability to make introductions) and another for shared groups. I've never liked how XEP-0144 muddied the waters of roster item sharing, which were much clearer in XEP-0093. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpctsMACgkQNL8k5A2w/vwzcACeNM7pndb2Uw75ZOLfF0QBqgjp S8AAn31k3tqgUGhvxEfkgs66G6nmDUPk =iNw8 -----END PGP SIGNATURE-----
