Typos, completed some examples and paragraph clarifications thanks to badlop feedback.
Add hat creation and detruction flows; add hue optional parameter; add chatroom presence hats broadcast; complete disco#info; clarify how the service should broadcast updated hats; typos; standardize the form fields;
Select a syntax for hats.
Initial published version approved for publication by the XMPP Council; clarified ad-hoc commands logic and syntax.
Described use of ad-hoc commands for adding and removing hats.
First draft.
Multi-User Chat (XEP-0045)
A room in a MUC service that supports hats MUST advertise a Service Discovery (XEP-0030)
The "hat list" and all associated commands are OPTIONAL. Some of the commands might be restricted by some business logic or internal rules (such as a LDAP configuration where the hats are already preconfigured).
If the room has a list of hats configured, it should advertise it in its 'muc#roominfo' extension form by computing a unique hash based on the list of hats URIs provided. The way the hash is computed is left to the implementer.
If the requesting entity detects that, based on a mismatching hash, the localy stored hats list is considered outdated.
MUC already includes a way for the room to signal the roles and affiliations of room occupants. Hats are signalled in a similar way. A participant can wear many hats. The following example shows a participant who is a MUC room owner and both a "host" and a "presenter" in an online meeting system. This system also demonstrates how hats can be annotated with custom information (here, the example <badge/> element).
Every hat is uniquely identified by its URI. Hats also carry a human-readable title for display purposes. Within XMPP, a hat is contained within a <hat/> element in the 'urn:xmpp:hats:0' namespace. This element MUST possess a 'uri' attribute (containing the hat's URI), a 'title' attribute containing the name of the hat for display purposes, MAY contain an 'xml:lang' attribute that identifies the language used in the 'title' attribute and MAY contain a Hue Angle color that define the hat color to apply. The <hat/> element MAY contain additional custom payloads defined by other XEPs, or payloads specific to an implementation or deployment.
Entities may have multiple hats. The <hats/> element is defined as a container of zero or more <hat/> elements.
Hats are created and destroyed using Ad-Hoc Commands (XEP-0050)
The following flow shows how to create a hat.
Updating a hat follows the same flow but set an existing "hats#uri". If a hat is updated the room SHOULD broadcast the related JID presences with the refreshed hat list.
When any change is applied to the hats list the room SHOULD broadcast a notification that the configuration changed to all users present.
The following flow shows how to destroy a hat and remove it from the list of available hats.
It first asks the formulary, which returns a list of all the available hats, and then actually requests to destroy one of them. Notice that alternatively, the client may send directly the query to destroy a hat without first requesting the formulary, as it already knows many hats that were received in presence stanzas.
When a hat is destroyed, it is automatically removed from all the JIDs where it was assigned.
The room SHOULD broadcast the related JID presences with the refreshed hats list.
An entity might be interested to get all the existing hats available in a chatroom.
Hats are assigned and removed using Ad-Hoc Commands (XEP-0050)
The following flow shows how to assign a hat.
Unless an error occurs, the room returns the appropriate form.
Note: only one hat is added at a time, and the form uses a field of type "list-single" to enforce that logic.
The following flow shows how to remove a hat.
When the hat is removed, the room SHOULD broadcast the related JID presence with the refreshed hat list.
An entity might be interested to get all the hats assigned to users in a chatroom.
Field Standardization for Data Forms (XEP-0068)
urn:xmpp:hats:commands
XEP-0317
Forms enabling the creation, destruction, assignal and removal of hats.
To follow.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
The XMPP Registrar shall add "urn:xmpp:hats:0" to its registry of protocol namespaces.
To follow.
The concepts underlying this specification were first discussed several years ago at an XMPP Summit in Brussels, Belgium. Special thanks to Joe Hildebrand and Ralph Meijer for their contributions to those discussions. Thanks also to Matt Miller, Kevin Smith, Matthew Wild and badlop for their feedback on the written specification.