Re: [Standards] Avatars
Hi, On Mon, Aug 22, 2011 at 4:07 AM, Florian Zeitz wrote: > On 21.08.2011 20:15, Kevin Smith wrote: >> On Sun, Aug 21, 2011 at 6:20 PM, Florian Zeitz wrote: >>> I think we might need a PubSub profile that allows more configurability >>> in terms of who may see what data (this is quite interesting in terms of >>> most social networking related work too). >> >> That's XEP--0060, isn't it? I realise most servers choose to only >> implement the minimal -163 subset, but I hope this will move towards >> full -60 support over time. >> >> /K > > After double checking turns out for the access-model configuration > that's even PEP (MUST support presence, open, roster, and whitelist). Yes PEP already supports other models. That's in the same section (5. Recommended Defaults) of PEP where they say the default should be "presence". So I was definitely not advocating "only" for more configurability, but for a default which I think is most adapted to the rest of the world. Also if I dare to speak for the world, that's only because I cannot but notice that this is the current use of avatars: Gravatar is by far the most used avatar system (but centralized and totally not standard) and it has a fully public "access model". I guess most people just want their avatar to be set at one place, never to care about it again and then see it everywhere without restriction. But yes, I totally agree that configuration is a plus and we must totally not strip this feature out (that's also why I prefer the PEP to the vcard XEP). Just I'll prefer another default for this specific node. > I'm not sure how server support for this really is though. I can only say by test that the avatar node on ejabberd seems indeed accessible to the roster only. I will make some tests for configuration change on the node. I guess I'll be able to test on M-link as well with jabber.org. > Maybe we can encourage client developers to really give users that > choice in the UI? (Gajim appears to have some configuration interface to > modify existing nodes [that I have never had working], but general > choices what to do when creating e.g. an avatar node I have not seen > anywhere yet) Yes. But even though it is internally used as "node configuration", on user point of view, that's just their avatar access. When users change avatar for instance, a user should just have to check a box "keep it private (roster only)" or something similar. Nothing more complicated. Jehan
Re: [Standards] Avatars
On 21.08.2011 20:15, Kevin Smith wrote: > On Sun, Aug 21, 2011 at 6:20 PM, Florian Zeitz wrote: >> I think we might need a PubSub profile that allows more configurability >> in terms of who may see what data (this is quite interesting in terms of >> most social networking related work too). > > That's XEP--0060, isn't it? I realise most servers choose to only > implement the minimal -163 subset, but I hope this will move towards > full -60 support over time. > > /K After double checking turns out for the access-model configuration that's even PEP (MUST support presence, open, roster, and whitelist). I'm not sure how server support for this really is though. Maybe we can encourage client developers to really give users that choice in the UI? (Gajim appears to have some configuration interface to modify existing nodes [that I have never had working], but general choices what to do when creating e.g. an avatar node I have not seen anywhere yet) -- Florob
Re: [Standards] Avatars
On Sun, 2011-08-21 at 19:20 +0200, Florian Zeitz wrote: > Personally I'd like to see us moving from XEP-0054/XEP-0153 to a > XEP-0292/XEP-0084 combination, where the former is just vCard and the > later avatar. +1 > BTW I'm among those that would prefer using just PEP for vCard4. > Having one node for the hash and one for the actual data. You can > still get the vCard with an appropriate item fetching IQ and MEP is > something it would be nice to see move forward anyway. Yeah, what exactly does the current method gain us over ? -- Kim Alvefur
Re: [Standards] Avatars
On Sun, Aug 21, 2011 at 6:20 PM, Florian Zeitz wrote: > I think we might need a PubSub profile that allows more configurability > in terms of who may see what data (this is quite interesting in terms of > most social networking related work too). That's XEP--0060, isn't it? I realise most servers choose to only implement the minimal -163 subset, but I hope this will move towards full -60 support over time. /K
Re: [Standards] Avatars
On 21.08.2011 16:18, Jehan Pagès wrote: > Hi, > > I am looking more closely to avatars. > Right now, we have 4 specifications (more?) that can carry avatars: > - XEP-0008: obsolete; > - XEP-0054/XEP-0153: vcard-based (vcard-temp), historic; > - XEP-0084: PEP-based; draft; > - XEP-0292: vcard4-based, and a part PEP. > > Ok so I won't speak about XEP-0008. I think it is dead and too basic. > > Still I see 2 issues I'd like to raise: > > 1/ Now we still have 3 protocols! XEP-0153 seems to still be the most > used of them all, though it looks like at term, it should be replaced > by XEP-0084. Or am I wrong? Is is safe to assume, if you had to > choose, then you must implement XEP-0084 instead of 0153? > And what about the brand new XEP-0292? Shouldn't we begin to stick to > some protocol and improve it instead of constantly create new > protocols? Because avatars in XMPP are a real mess. And this vcard-4 > is not on the path to improve this fact. > Some general notes here: Just like XEP-0054, XEP-0292 does NOT specify a way to do avatars. It maps vCard4 to XMPP and is huge step forward from the unfinished, strange XML representation of vCard we had before. It does however map PHOTO (which IMHO is specifically not an Avatar, since avatars do not necessarily show a photo of the account owner) and LOGO (which might be closer to an avatar...). At any rate I dislike the idea of restricting our use of vCard4 to remove potentially large data. Personally I'd like to see us moving from XEP-0054/XEP-0153 to a XEP-0292/XEP-0084 combination, where the former is just vCard and the later avatar. BTW I'm among those that would prefer using just PEP for vCard4. Having one node for the hash and one for the actual data. You can still get the vCard with an appropriate item fetching IQ and MEP is something it would be nice to see move forward anyway. > 2/ As I said, I think anyway XEP-0084 is nicer. But I see PEP has a > default access-model of "presence" (section 5 of XEP-0163). While in > many case, that could be more secure, for an avatar though, I would > say a default of "open" would be the best (for this specific avatar > node, not necessarily for any PEP node). > Personally I'd really like my avatar node to have a "presence" access-model. I think what you might be really advocating here is having more configurability for PEP nodes. I think we might need a PubSub profile that allows more configurability in terms of who may see what data (this is quite interesting in terms of most social networking related work too). -- Florob
[Standards] Avatars
Hi, I am looking more closely to avatars. Right now, we have 4 specifications (more?) that can carry avatars: - XEP-0008: obsolete; - XEP-0054/XEP-0153: vcard-based (vcard-temp), historic; - XEP-0084: PEP-based; draft; - XEP-0292: vcard4-based, and a part PEP. Ok so I won't speak about XEP-0008. I think it is dead and too basic. Still I see 2 issues I'd like to raise: 1/ Now we still have 3 protocols! XEP-0153 seems to still be the most used of them all, though it looks like at term, it should be replaced by XEP-0084. Or am I wrong? Is is safe to assume, if you had to choose, then you must implement XEP-0084 instead of 0153? And what about the brand new XEP-0292? Shouldn't we begin to stick to some protocol and improve it instead of constantly create new protocols? Because avatars in XMPP are a real mess. And this vcard-4 is not on the path to improve this fact. If I were to choose, I would prefer the PEP protocol to the vcard4 protocol. That's not to say not to use vcard4 otherwise, but remove any examples about avatars in XEP-0292, and add a note inside to say that use of vcard for saving avatar is now deprecated and XEP-0084 is preferred. Also, to add to the mess, I see vcard-4 has a PHOTO and a LOGO properties with basically description which I find totally similar! 2/ As I said, I think anyway XEP-0084 is nicer. But I see PEP has a default access-model of "presence" (section 5 of XEP-0163). While in many case, that could be more secure, for an avatar though, I would say a default of "open" would be the best (for this specific avatar node, not necessarily for any PEP node). My use case is simple: basically replace gravatar or any similar centralized attempts. If we want to be able to do so, avatars should be accessible without having presence. Any service which has itself some JID (hence able to connect to the federation) should be able to subscribe without being a contact. First because we don't want to have dozen of bots in our roster, for all the services we visited sometimes only once (but still think it is nice to display one's avatar there); and also because a "normal" pubsub subscription is actually much more powerful than a +notify presence. The presence "auto-subscription" basically asks to always get notified each time you send your presence. That's ok for one's roster, but if we begin to have a lot of service subscribing to one's avatar, it is much more efficient for the service to store your avatar, and simply get notified each time it is changed, without ever having to query again (I mean: querying when it is useless. The service query the new avatar only when it received a notification of change. Compared to something like gravatar, where you constantly query by http an avatar each time you display it, that's extremely efficient). Thanks. Jehan
