XSF Discussion - 2022-11-21

  1. edhelas

    I have some standard problem with Hats, it seems that the only client implementation in the wild (conversejs) is doing some kind of non-standard things, compatible with Prosody (the module was developped for conversejs)

  2. edhelas

    And I see that ejabberd is having some kind of support

  3. edhelas


  4. edhelas

    But I'm not sure if its the conversejs way or the official XEP-0317 way, I was not able to make it work with ejabberd from the XEP flow :/

  5. edhelas

    jcbrand Holger Zash, any though ?

  6. MattJ

    edhelas, XEP-0317 needs work. The most important thing is the display of hats, which is something I think we can all vaguely agree on already.

  7. MattJ

    The part that is still up in the air, is how to assign hats. That, in my experience, is something very specific to a given deployment. The XEP gives lots of possibilities of how hats can be used, but in reality most of them (e.g. student/teacher) will be coming from a backend auth database, rather than being assigned by clients.

  8. MattJ

    I'm not really sure what parts ejabberd implements currently, but I'd be interested

  9. MattJ

    Also I'm not sure what you mean by the "official XEP-0317 way"

  10. MattJ

    It basically doesn't define a syntax for hats currently (well, it defines multiple)

  11. edhelas

    Yeah, to me I have more questions than aswers for that XEP

  12. edhelas

    But I'd be very happy to be part of a small development jam to work on it

  13. MattJ

    Let's do it

  14. edhelas

    I was wondering if it would be possible to have some funding for such thing ? Like we set a date and a place in Europe, we ask who would like to join and we see how we can cover the expenses. I can see other jams like this, for example for the multi-user video conferencing thing :)

  15. MattJ

    I don't know if we even need that

  16. MattJ

    I've got a basic diff for the XEP for the hat syntax already

  17. edhelas

    For that XEP a small remote jam could be enough yes

  18. MattJ

    We only need to decide if there will be a protocol for users to add/remove their own hats, a protocol for admins to add/remove hats of users, and if we decide 'yes' for either of those, determine if they should use ad-hoc commands or not

  19. edhelas

    If we have a few servers and clients devs interested about around the table it would be perfect :)

  20. edhelas

    Yes :) !

  21. edhelas

    To me I'd prefer to have more of a XMPP - IQ based protocol, ad-hoc is a bit to high level for such thing no ?

  22. edhelas

    Like I just discover the Hats capabilities with the MUC caps, then I just send some forms to the MUC if possible as a user and/or admin

  23. MattJ

    Me too. And I already have such a protocol, I have a hats.txt locally (but I never implemented it IIRC). Let me see if I can dig it up...

  24. edhelas

    The hats will be broadcasted with the presences ?

  25. MattJ

    Yes, same as the XEP already says

  26. edhelas

    I'm ok with that, I have some buffers to mass handle them and insert in the DB

  27. edhelas

    Perfect 👌

  28. edhelas

    Also, there a notion of colors that could be used for the hats.

  29. MattJ


  30. MattJ

    Yeah, we could add that

  31. MattJ

    But then how far do we go? Icons? Animated GIFs? :)

  32. Kev

    Why not?

  33. Kev

    Or, rather, if someone wants that, there's no reason they shouldn't be able to extend the hat definition with what they need.

  34. MattJ

    If the hat has a URI recognised to the client, the client can of course decorate it however it wants

  35. MattJ

    Kev, hats (at least in my unpublished draft) may contain arbitrary custom payloads. But that's not the same as e.g. a standard field that tells clients (even if they don't recognise a certain hat) what colour it should be displayed with.

  36. Kev

    I do think there's value in including colour in the core spec, but things like animated GIFs can easily be added is child elements.

  37. Kev

    I do think there's value in including colour in the core spec, but things like animated GIFs can easily be added in child elements.

  38. Kev

    MattJ: Right.

  39. jonas’

    please include colour as a '394 angle value instead of RGB :-)

  40. jonas’

    easier to make accessible

  41. jonas’

    s/angle/hue/, if you like

  42. Zash

    Hats and Security labels!

  43. MattJ

    See, even colour is contentious :)

  44. Zash


  45. edhelas


  46. edhelas

    The Discord way should be "good enough" to me, and yes we can make it compatible with accessiblity :)

  47. edhelas

    MattJ I don't see the difference between <list> and <current>

  48. MattJ

    edhelas, <list> shows you what hats are available in this room, <current> shows you what hats you are currently wearing

  49. edhelas

    Not a big fan of the <doff>/<don> (what do they means ?) thing as well, I'd prefer a <set>/<remove>

  50. MattJ

    Yes, I'm in favour of that. It's just a funny quirk from the original XEP I preserved :)

  51. edhelas

    The rest seems file to me :) A think some caps should help the clients for their UI setup. urn:xmpp:hats:1#set_admin_only or things like that

  52. edhelas

    And this can be configured in the MUC config form

  53. MattJ

    On the server side it's quite complicated

  54. edhelas

    Ah :p

  55. MattJ

    We want to support hats that people can choose to wear or not wear, and also hats that they are forced to wear

  56. MattJ

    For example, in the education example, you might not want a teacher to be able to remove their teacher hat and pretend to be a student

  57. edhelas

    Ah yes indeed :/

  58. MattJ

    They might even be an admin of the room

  59. edhelas

    Got an idea on that ?

  60. MattJ

    But still the deployment would always announce them as a teacher

  61. MattJ

    Well it's kind of done already, in Prosody

  62. MattJ

    See https://modules.prosody.im/mod_muc_hats_api and the 'Data model' section

  63. MattJ

    So there are hats that default to on, hats that default to off, and hats that are required to wear (for users they apply to)

  64. edhelas

    So you present the list differently for each users, seems good to me

  65. MattJ

    From a protocol perspective it's not hard. The server will just automatically include the required/default hats in presence, and show voluntary hats to users via the list command.

  66. edhelas

    So the difference with Discord would be that users that are not admin will be able to set/unset some hats

  67. MattJ

    They can do that in Discord? or not?

  68. Kev

    I note that on Discord it's always server-assigned hats(roles), and people then have creative ways of allowing users to self-assign roles by having admin bots.

  69. edhelas

    (in Discord its only set by admins AFAIK)

  70. Kev

    Heh, perfect timing.

  71. edhelas

    Yes this

  72. MattJ

    I think it's easy enough for us to have self-service hats part of the protocol in XMPP

  73. edhelas

    To me its also a good solution, because then you can have "clever bot" that can handle that

  74. Kev

    The usual way on Discord is > To assign yourself roles on this server, react to this message. 🤣for the 'Kev' role, 😍for the XMPP role

  75. Kev

    > I think it's easy enough for us to have self-service hats part of the protocol in XMPP Yes, and given that people are already using bots as a workaround on Discord, this seems very sensible to do. Also possibly flagging which roles/hats are self-service, and which are not, in a given context.

  76. MattJ

    It doesn't mean you can't do it the bot way, but I don't see why we can't also allow clients to provide a nicer UI around it

  77. edhelas

    Kev and accept the 20 pages of rules, send a private message to an admin, and then wait 1 week to be in and find out the server is kinda dead for 2 years :p

  78. edhelas

    MattJ to me I'd actually prefer as a client to see the full hats list and have some XML parameters on it to know if they can be set by myself or an admin

  79. edhelas

    <hat uri="http://tech.example.edu/hats#Teacher" title="Teacher" settable="true"/>

  80. edhelas

    Helps with the "discoverability", the user can then ask the admin to allow him to get a forbidden role

  81. MattJ

    Makes sense. I might look for an alternative indication mechanism to modifying the <hat/> element, but I agree it would be good to make restricted hats discoverable (if the server allows exposing them)

  82. MattJ

    If you've no other immediate feedback, I can polish off my draft update and share a proposal for the new XEP-0317 this week

  83. MattJ

    Then if we're all happy, submit it

  84. Kev

    > MattJ to me I'd actually prefer as a client to see the full hats list and have some XML parameters on it to know if they can be set by myself or an admin That's what I was suggesting, too.

  85. edhelas

    To me that should arlready a good base to work on :)

  86. edhelas


  87. edhelas

    And I'd be really happy to add it in Movim (once the servers guys figure out how to implement it :p)

  88. MattJ

    I can provide a test server

  89. edhelas

    (it's weird that I don't have MAM detected on this MUC, with stanza-id I can then add a reaction to the messages)

  90. edhelas

    (ah, might be a bug on my side)

  91. emus

    Please remind: We are inviting for a XMPP End of the Year Talk 2022! Listen in, Meet & Greet, talk & discuss - but mainly have a good time with the XMPP Community folks! Feel free to announce your topics or software to present, discuss about so we can announce when it comes closer! Just reply to this mail or catch me in the chat (--> emus). - Goffi will have a short talk. When: 6th Dec 2022, 19:00 CET Join via Jitsi instance: https://teamjoin.de/XMPP_EndOfTheYearTalk2022 Talk to you soon, Ed

  92. edhelas

    <presence to='miho@movim.eu/movimhbo6dQ' from='xsf@muc.xmpp.org'><x xmlns='vcard-temp:x:update'><photo>b85aee85ddb23a4c1111c7d43ba6ab9afd76c552</photo></x></presence>

  93. edhelas

    Not capabilities in this room presence ?