[Standards] Obsoleting vCard-Based Avatars
tmarkmann at googlemail.com
Wed Jan 11 19:57:38 UTC 2017
On Wed, Jan 11, 2017 at 5:44 PM, Sam Whited <sam at samwhited.com> wrote:
> On Tue, Jan 10, 2017 at 11:04 AM, Kevin Smith <kevin.smith at isode.com>
> > FWIW, give the remaining widespread deployment of vcard avatars compared
> > pubsub-based, and of reported lack of interop between 84 implementations
> > (I'm sure I remember being told that some clients aren't sending
> > formats), it seems premature to me to obsolete these.
> In my mind this shouldn't be a consideration; if you don't give people
> a compelling reason to upgrade, I don't think they will. Normally this
> would be in the form of new features, or something that's easier to
> maintain. In this case, however, 0084 doesn't provide anything but
> better infrastructure to build on (and no one cares about
> infrastructure, it's not shiny enough). Simiarly, some clients not
> sending mandatory formats doesn't seem like a reason not to use 0084
> (clients could just as easily send a different format via 0153).
> If we want the ecosystem to move forward, I think the closest thing we
> can provide to a compelling reason is to make 0084 the only
> recommendation for new implementations (old implementations will fall
> into line when they're no longer compatible with any of the shiny new
> clients). Right now there are two separate XEPs which serve the same
> purpose, and both show up on xmpp.org with green text at the top. The
> confusion this causes is, in my opinion, much worse than the
> outstanding issues with 0084, and by encouraging implementations of
> 0084 by making it the only recommendation we may also encourage
> contributions to fix those outstanding issues.
We certainly should have a single standard that covers the UX of sharing an
avatar photo, that works in the roster and in group chats, may they be MUC
or MIX group chats. If we want XEP-0084 to be that standard, it should
ideally cover workaround to make it work in MUC scenarios where it
currently does not. A good started would be that the issues are at least
discussed in XEP-0084.
Clients not using the mandatory image encoding for XEP-0084 definitely is
no reason to push for further implementations of it by marking XEP-0153 as
Historic. The same clients probably don't use the mandatory image encoding
for XEP-0153 either. To further help adoption of XEP-0084, it could be made
part of 2017s compliance suites. However, for that it should work in the
scenarios where XEP-0153 worked as we certainly don't want to fallback to a
worse UX, right?
So what are the scenarios in which XEP-0084 doesn't work? What is required
to make it work in these scenarios? Is server support required for that
(probably)? Will it work flawlessly with MIX?
XEP-0084 is based on PEP, which requires knowledge of a bare JID and a
presence subscription to that JID. Bare JIDs are not known in anonymous and
semi-anonymous MUCs. Another issue is that in semi-anonymous rooms, admins
can leak their JID by doing requests to the known full JIDs. MUCs could
stamp out local anonymous bare JIDs for this case and present them in the
MUC similar to MIX's proxy JID idea. However that's probably quite some
Does somebody have an idea how to fix this issue in a more lightweight way?
Eventually we'll move to MIX in the future I suppose, but that's certainly
not going to happen this or next year, at least if you still want to
interop with more than a single client.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards