I just reviewed the XEP-xxxx: MUC Avatars and I would like to discuss some ideas about it before proposing adjustments.
The core idea of this XEP is to expose the Vcard hash in the bare MUC JID disco#info and notify it using a message 104. This is a really specific use case that solves a really specific problem. However the method that is used in this XEP to store this hash could be generalized to other cases. I see two things there: - How are we storing the avatar hash (here in a specific field in disco#info) - How this hash is advertised to the subscribers disco#info is a pretty generic feature in XMPP that is actually already applied to most of the resources available on the network including: - MUC JIDs - Users JIDs - Pubsub nodes What I'd like to propose is to generalize this XEP to allow this method to be used across all those resources, this will allow to have a unified method (it maybe sounds like https://xkcd.com/927/) to handle the retrieval of Avatars and also finally allow Pubsub nodes to have an avatar (and Vcard information as well if possible, see my last point). This brings me to the second part of my proposal. How to advertise the change. - For MUC, I'd suggest to stick with the status code='104' even if I'd prefer to use XEP-0153 presences for that - For Users JIDs, simply stick with XEP-0153 - For Pubsub nodes it could also reuse XEP-0153 in a Pubsub notification as a payload Last proposal would not be to mention only Avatar but simply Vcard (vcard-temp in this case) then we could put more metadata in this payload (add an address to a Pubsub node for example) but I'd like to have more feedback on that one. In any cases I'll try to formalize those proposals in a PR to this XEP :) Regards, Timothée Jaussoin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
