Pedro Melo wrote: <snip/>
I'll let the XEP authors comment on your feedback. :) > 5. Final thoughts > > I must admit that the lack of private storage in the GTalk service is a > big turn off for us. Perhaps they will deploy PEP someday. :) > If we are willing to loose the order attribute (and I would not like > that, but I want something that just works), there is a fallback > protocol that requires only the usual roster to keep meta-contacts. If > we assume that roster items with the same name + groups (basically, if > the tag algorithm above yields the same hash for your roster entries) > belong to the same meta-contact, we can implement meta-contacts without > the need of any extra storage, just the roster. > > The two down-sides are: > > 1. you must rename the roster entries and stick them in the same groups > if they belong to the same meta-contact: personally I have no problems > with this, because it works pretty well even if I log in with a contact > without meta-data support. > 2. you loose the user-order of contacts inside a meta-contact: so you > have to revert to the usual presence priority. > > We used this method (client-side calc of hash based on the above > algorithm) in our windows client for 5 years now, with good results. This is interesting. Are you saying that we don't need private data storage or PEP at all for Metacontacts? That would certainly simplify the deployment task. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
