30 Jun
2025
30 Jun
'25
4:16 a.m.
A few weeks ago I made an important pull request to complete, fix and
update the XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
* Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the
available list
* Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat
from the list
* Clarify how the service should broadcast the hat changes when it is
edited, assigned, removed or destroyed
* Specify a way for an entity to get the complete list of hats using a
hash in disco#info
* Add a hue optional parameter allowing entities to assign a color to
the hat that can be displayed properly in any conditions on the
client (as explained in XEP-0392: Consistent Color Generation)
* Standardize all the form fields using XEP-0068
* Fix some typos
I tried to reach the authors without success so I'm trying again using
the mailing list.
I'd really like to move it forward then we can start implementing them
in our clients and servers.
Regards,
edhelas
30 Jun
30 Jun
6:26 a.m.
Hi Timothée, thanks for working on this. Comments inline.
On 6/30/25 4:16 AM, Timothée Jaussoin wrote:
A few weeks ago I made an important pull request to
complete, fix and
update the XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
* Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the
available list
* Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat
from the list
* Clarify how the service should broadcast the hat changes when it is
edited, assigned, removed or destroyed
* Specify a way for an entity to get the complete list of hats using a
hash in disco#info
* Add a hue optional parameter allowing entities to assign a color to
the hat that can be displayed properly in any conditions on the
client (as explained in XEP-0392: Consistent Color Generation)
* Standardize all the form fields using XEP-0068
* Fix some typos
Overall these changes seem reasonable.
I have a few questions:
How are clients supposed to process the hash of supported hats, given
that the hash-calculation method is implementation-specific? It seems
that the client needs to cache the hash, then retrieve the list of hats
if the hashes don't match. Is that all?
When a hat is destroyed, are participants who had that hat informed?
I tried to reach the authors without success so
I'm trying again using
the mailing list.
This puzzles me. If you ever need to ping me on GitHub, just flag
@stpeter - and I would think that Matthew is very easy to find in
chatrooms etc.
I'd really like to move it forward then we can
start implementing them
in our clients and servers.
Sounds great.
For historical purposes, you might find it interesting that my original
motivation for defining Hats was to support in XMPP some of the features
that existed in WebEx (I worked on the WebEx team at that time). It's
interesting to me that such features are still useful. :-)
Peter
6:35 a.m.
Hi!
Thanks for the (quick) feedback !
My answers bellow:
Le 30/06/2025 à 14:26, Peter Saint-Andre a écrit :
Indeed I didn't pinged you on GitHub, only tried to reach you on
XMPP :)
Next time I'll do it this way.
Interesting indeed, on my side I have lots of nice ideas around hats in
Movim, this XEP PR will help a lot for sure :)
Hi Timothée, thanks for working on this. Comments
inline.
On 6/30/25 4:16 AM, Timothée Jaussoin wrote:
Yes, I could add a section that
enforce a specific hash-calculation, but
as a client developer caching seems "good enough" to me.
A few weeks ago I made an important pull request
to complete, fix and
update the XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
* Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the
available list
* Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat
from the list
* Clarify how the service should broadcast the hat changes when it is
edited, assigned, removed or destroyed
* Specify a way for an entity to get the complete list of hats using a
hash in disco#info
* Add a hue optional parameter allowing entities to assign a color to
the hat that can be displayed properly in any conditions on the
client (as explained in XEP-0392: Consistent Color Generation)
* Standardize all the form fields using XEP-0068
* Fix some typos
Overall these changes seem reasonable.
I have a few questions:
How are clients supposed to process the hash of supported hats, given
that the hash-calculation method is implementation-specific? It seems
that the client needs to cache the hash, then retrieve the list of
hats if the hashes don't match. Is that all?
When a hat is destroyed, are participants who had that hat informed?
I have this small paragraph to cover that case:
/The service SHOULD broadcast the related JID presences with the
refreshed hats list./
I tried to reach the authors without success so
I'm trying again
using the mailing list.
This puzzles me. If you ever need to ping me on GitHub, just flag
@stpeter - and I would think that Matthew is very easy to find in
chatrooms etc. I'd really like to move it forward then we
can start implementing
them in our clients and servers.
Sounds great.
For historical purposes, you might find it interesting that my
original motivation for defining Hats was to support in XMPP some of
the features that existed in WebEx (I worked on the WebEx team at that
time). It's interesting to me that such features are still useful. :-)
Peter
6:41 a.m.
On 6/30/25 6:35 AM, Timothée Jaussoin wrote:
Indeed I didn't pinged you on GitHub, only tried to reach you
on XMPP :)
Next time I'll do it this way.
Ironically [1] I haven't been logged into XMPP much lately, but I tend
to notice when people or systems send me email messages.
Interesting indeed, on my side I have lots of nice ideas around hats in
Movim, this XEP PR will help a lot for sure :)
Excellent!
Peter
[1] https://stpeter.im/journal/538.html
Hi!
Thanks for the (quick) feedback !
My answers bellow:
Le 30/06/2025 à 14:26, Peter Saint-Andre a écrit :
Ah, sorry, I missed that. Reading too fast.
Hi Timothée, thanks for working on this. Comments
inline.
On 6/30/25 4:16 AM, Timothée Jaussoin wrote:
Yes, I could add a section that
enforce a specific hash-calculation, but
as a client developer caching seems "good enough" to me.
A few weeks ago I made an important pull request
to complete, fix and
update the XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
* Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the
available list
* Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat
from the list
* Clarify how the service should broadcast the hat changes when it is
edited, assigned, removed or destroyed
* Specify a way for an entity to get the complete list of hats using a
hash in disco#info
* Add a hue optional parameter allowing entities to assign a color to
the hat that can be displayed properly in any conditions on the
client (as explained in XEP-0392: Consistent Color Generation)
* Standardize all the form fields using XEP-0068
* Fix some typos
Overall these changes seem reasonable.
I have a few questions:
How are clients supposed to process the hash of supported hats, given
that the hash-calculation method is implementation-specific? It seems
that the client needs to cache the hash, then retrieve the list of
hats if the hashes don't match. Is that all?
When a hat is destroyed, are participants who had that hat informed?
I have this small paragraph to cover that case:
/The service SHOULD broadcast the related JID presences with the
refreshed hats list./ I tried to reach the authors without success so
I'm trying again
using the mailing list.
This puzzles me. If you ever need to ping me on GitHub, just flag
@stpeter - and I would think that Matthew is very easy to find in
chatrooms etc. I'd really like to move it forward then we can
start implementing
them in our clients and servers.
Sounds great.
For historical purposes, you might find it interesting that my
original motivation for defining Hats was to support in XMPP some of
the features that existed in WebEx (I worked on the WebEx team at that
time). It's interesting to me that such features are still useful. :-) 
2 Jul
2 Jul
5:30 a.m.
On Mon, 30 Jun 2025 at 11:16, Timothée Jaussoin <edhelas(a)movim.eu> wrote:
A few weeks ago I made an important pull request to complete, fix and update the
XEP-0317: Hats.
https://github.com/xsf/xeps/pull/1437
This PR included the following changes:
Specify a urn:xmpp:hats:commands:dcreate command to add a hat to the available list
Specify a urn:xmpp:hats:commands:ddestroy command to destroy a hat from the list
Clarify how the service should broadcast the hat changes when it is edited, assigned,
removed or destroyed
Specify a way for an entity to get the complete list of hats using a hash in disco#info
Add a hue optional parameter allowing entities to assign a color to the hat that can be
displayed properly in any conditions on the client (as explained in XEP-0392: Consistent
Color Generation)
Standardize all the form fields using XEP-0068
Fix some typos
I tried to reach the authors without success so I'm trying again using the mailing
list.
I'd really like to move it forward then we can start implementing them in our clients
and servers.
Sorry, I did actually respond in xsf@ the day after you submitted the
PR but I understand it was easily missed.
I mentioned that I'm fine with these changes, as long as the commands
are optional for the server. I still don't see any text explicitly
stating this, and I wouldn't want the XEP to mandate that these
commands are always available.
The reason is that a lot of deployments I have worked on that use hats
typically pull this information from another source of truth (for
example, LDAP or some database) and do not allow free creation of
hats. For example, in certain deployments it wouldn't be okay for a
student to create a group chat, create a "Teacher" hat, and then
assign it to themselves and/or their friends.
Obviously if you want to build a client management UI for hats,
because you are building a public self-service platform (such as, you
mentioned, Discord), then it's good to have standard commands for
these operations in XMPP.
Also, a minor nit, but it might be nice to make the command nodes a
bit more sensible. They don't make sense as the XEP has evolved. I'll
leave some comments inline.
Regards,
Matthew
28
days inactive
30
days old
4 comments
3 participants
participants (3)
-
Matthew Wild -
Peter Saint-Andre -
Timothée Jaussoin