From 6e8b3c0a59e1c4f83782cf578ee667191ebe7ca3 Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Mon, 27 Aug 2018 19:21:26 +0200 Subject: [PATCH] ProtoXEP: MUC Avatars --- inbox/muc-avatars.xml | 306 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 306 insertions(+) create mode 100644 inbox/muc-avatars.xml diff --git a/inbox/muc-avatars.xml b/inbox/muc-avatars.xml new file mode 100644 index 00000000..967cd3f5 --- /dev/null +++ b/inbox/muc-avatars.xml @@ -0,0 +1,306 @@ + + +%ents; +]> + + +
+ MUC Avatars + This specification describes how to publish and retrieve avatars in rooms. + &LEGALNOTICE; + xxxx + ProtoXEP + Standard Track + Standards + Council + + XMPP Core + XEP-0030 + XEP-0045 + XEP-0054 + XEP-0068 + XEP-0153 + + + + NOT_YET_ASSIGNED + + Emmanuel Gil + Peyrot + linkmauve@linkmauve.fr + linkmauve@linkmauve.fr + + + 0.0.1 + 2018-08-21 + egp +

First draft.

 + +
+ +

Avatars are small images people often use to identify each other very quickly in chat applications. They are well defined for users, in &xep0084; and &xep0153;, but until now chat rooms all shared a default icon. This extension provides a way for owners to associates an avatar to their chat room, and for users to discover that an avatar is associated and display it accordingly.

+

XMPP services have traditionally allowed owners to set a vCard-temp on a MUC using &xep0054;, this extension tries to keep as much of it as possible so existing applications don’t have to be modified too much.

+

Some implementations recently chose to advertise those avatars using the existing &xep0153; extension in <presence/>, but it exposed issues in other implementations, and was only available when the user is already present in the room, not before joining it (for example when listing all available rooms).

+

A future extension superseding this one could define a method based on &xep0084;, with a PubSub service on the room’s bare JID containing the metadata and data nodes. Such a specification should also define a compatibility profile similar to &xep0398; for user avatars, enabling the coexistence of both versions until the present one is deemed obsolete.

+ + +

This specification SHOULD:

+
    +
  • Allow authorised entities to set an avatar on a MUC.
    • +
  • Allow authorised entities to remove a previously-set avatar on a MUC.
    • +
  • Allow users to discover an avatar is set on a MUC.
    • +
  • Allow users to request the avatar of a MUC.
    • +
  • Let users know that the avatar of a MUC changed while they are present in said MUC.
    • +
  • Let users discover the avatar even when not present in the MUC.
    • +
  • Stay as compatible as possible with the current usage of avatars in MUC.
    • +
+ + + +

Before trying to use avatars, a client must check that the group chat service hosting a room does support them.

+ + +]]> + + + + + + ... + +]]> + + +

Before anyone can see an avatar attached to the room, an owner or some other priviledged entity must publish a vCard-temp containing the avatar’s data, using the protocol defined in &xep0054;.

+ + + + image/svg+xml + PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiI+CiA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGZpbGw9InJlZCIvPgo8L3N2Zz4K + + +]]> + ]]> +

There is no other action required on the owner’s end.

+

If the room doesn’t support support avatars, it must return a service-unavailable error.

+ + + + +]]> +

If the user trying to publish an avatar isn’t allowed to do so, the room must return a forbidden error, see the Security Considerations.

+ + + + Only owners are allowed to set avatars. + +]]> +

The room should then broadcast a notification that the configuration changed to all users present.

+ + + + + + + + + + +]]> +

Setting an empty vCard unpublishes the avatar.

+ + +]]> + + +

At any point, whether it is during a join in order to display it in its UI, after having discovered the list of the rooms and to list them with additional information, or when receiving a <status code='104'/> configuration change notification, a user’s client can discover information about a room.

+ + +]]> +

If the room has had an avatar published, it should advertise it in its 'muc#roominfo' extension form, using the &xep0153; hash computation method.

+ + + + + + ... + + + http://jabber.org/protocol/muc#roominfo + + ... + + a31c4bd04de69663cfd7f424a8453f4674da37ff + + ... + + +]]> +

This 'muc#roominfo_avatarhash' will not be present when the room doesn’t have an avatar set.

+ + +

At this point the client knows the hash and can retrieve the room’s vCard-temp.

+ + +]]> + + + + image/svg+xml + PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiI+CiA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGZpbGw9InJlZCIvPgo8L3N2Zz4K + + +]]> +

The client then has to decode the <BINVAL/> content from base64, hash it with sha1 and compare it with the advertised hash, and if it matches uses it as the room avatar under the <TYPE/> media type.

+ + + +

An application MUST support the image/png media type, SHOULD support image/jpeg, image/gif and image/svg+xml, and MAY support additional formats.

+

A room SHOULD NOT include a 'muc#roominfo_avatarhash' field if it doesn’t have an avatar set.

+ + + +

Multiple <PHOTO/> elements may be present in a vCard, in which case they should all represent the same image and the 'muc#roominfo_avatarhash' field must contain a hash of all of them.

+ + + + image/svg+xml + PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiI+CiA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGZpbGw9InJlZCIvPgo8L3N2Zz4K + + + image/png + iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQMAAABJtOi3AAAAB3RJTUUH4ggVERoVAPsrMgAAAAlwSFlzAAALEgAACxIB0t1+/AAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAAEZ0FNQQAAsY8L/GEFAAAAIGNIUk0AAHomAACAhAAA+gAAAIDoAAB1MAAA6mAAADqYAAAXcJy6UTwAAAAGUExURf8AAP///0EdNBEAAAABYktHRAH/Ai3eAAAADElEQVQI12NgGNwAAACgAAFhJX1HAAAAAElFTkSuQmCC + + +]]> + + + + + + ... + + + http://jabber.org/protocol/muc#roominfo + + ... + + a31c4bd04de69663cfd7f424a8453f4674da37ff + b9b256f999ded52c2fa14fb007c2e5b979450cbb + + ... + + +]]> + + +

Some existing implementations send or expect a presence from the room’s bare JID in order to detect an avatar being published. This had several issues, with existing clients handling that as a presence from a user with an empty nick or downright triggering an error, and was only available if the client was already present in the room, preventing any usecase where it would get displayed before entering the room.

+

For those reasons, this XEP doesn’t encourage this way of advertising the presence of an avatar, but for reference it would look like a &xep0153; presence payload:

+ + + a31c4bd04de69663cfd7f424a8453f4674da37ff + + +]]> + + + +

A server should take care that only allowed entities can publish a vCard-temp on a MUC, for instance room owners or service administrators.

+ + +

This document requires no interaction with &IANA;.

+ + + +

The registrar shall add the following field to the 'muc#roominfo' data form:

+ + + http://jabber.org/protocol/muc#roominfo + XEP-XXXX + Form extension for avatar support in a Multi-User Chat (MUC) room. + + +]]> + + + + +

Thanks to the Ejabberd developers for their MUC vCard tutorial, and to Sam Whited and Matthew Wild for their feedback.

+ +