On Thu, Apr 7, 2011 at 12:13 AM, Dave Cridland <d...@cridland.net> wrote: > On Wed Apr 6 19:55:17 2011, Waqas Hussain wrote: >> >> Also, PEP in MUC is not a solved problem. I do like avatars in MUC. > > I'd note that in Belgium, the consensus seemed to be to solve that problem > rather than continue to work around it. Additionally, a recall the consensus > as being to deprecate vcard4-for-avatars in favour of XEP-0084. >
+1 to solving that problem. XEP-0084's way is sensible. It does have issues though, described later. Aside: I note XEP-0084 has an example with an avatar posted at a HTTP URL. XEP-0153 explicitly said "The <PHOTO/> element SHOULD NOT contain an <EXTVAL/> that points to a URI for the image file." Has our stand on the data leak changed? >> All that said, I would really really love to have a generic framework >> to do for PEP and pubsub and disco and everything what we currently do >> for avatars via hash in presence. We added hashes in presence to avoid >> iq:avatar, iq:disco and iq:version floods on login. When we start >> having large data in PEP/PubSub, PEP floods are going to become a >> serious problem. >> >> One obvious solution is a 'hashes' node in PEP. You subscribe to that, >> and you get hash updates. A hash update is a set of hashes for avatar, >> versions, custom namespace, etc. You send a manual request for what >> you want to actually get, and cache the result for the future. It >> would be nice to have this also requestable via IQ (possibly a pubsub >> IQ). > > Perhaps a subscription option? > > We treat PEP's auto-subscribe from the bare jid, plus filtered > notifications, as an auto-subscribe from each full-jid, incidentally, which > makes this easier (if semantically wrong), but if these subscriptions could > (by dint of an additional disco#info feature advertised via caps) indicate > that a they only wishes to receive a hash of the last item on subscribe, > that might work. What's the hashing function? We don't have a standardized hashing function for arbitrary XML payloads in the XMPP community. Perhaps id of the last item would work. > But I suspect it places us into a canonicalization trap, and in any case it > will increase, not decrease, the number of stanzas. > > Alternatives are to send a timestamp with initial presence - possibly > managed by the server on a per contact basis to mitigate the privacy issues. What timestamp? Unless you send a per-PEP-node-per-contact timestamp, you get issues where you miss one update, and never know of it until the next change, and/or get a lot more updates than you need. (I note, timestamp here can be replaced by id or hash) > Dave. -- Waqas Hussain
