XSF Discussion - 2022-11-21

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)

And I see that ejabberd is having some kind of support

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/ZWaMZQEcFUoh/image.png

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 :/

jcbrand Holger Zash, any though ?

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.

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.

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

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

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

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

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

Let's do it

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 :)

I don't know if we even need that

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

For that XEP a small remote jam could be enough yes

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

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

Yes :) !

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 ?

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

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...

The hats will be broadcasted with the presences ?

Yes, same as the XEP already says

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

Perfect 👌

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

https://matthewwild.co.uk/uploads/hats.txt

Yeah, we could add that

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

Why not?

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

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

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.

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. ✏

MattJ: Right.

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

easier to make accessible

s/angle/hue/, if you like

Hats and Security labels!

See, even colour is contentious :)

coloÿur?

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/9qYoZg6Q0Eth/image.png

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

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

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

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

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

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

And this can be configured in the MUC config form

On the server side it's quite complicated

Ah :p

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

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

Ah yes indeed :/

They might even be an admin of the room

Got an idea on that ?

But still the deployment would always announce them as a teacher

Well it's kind of done already, in Prosody

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

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)

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

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.

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

They can do that in Discord? or not?

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.

(in Discord its only set by admins AFAIK)

Heh, perfect timing.

Yes this

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

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

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

> 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.

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

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

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

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

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

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)

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

Then if we're all happy, submit it

> 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.

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

*be

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

I can provide a test server

(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)

(ah, might be a bug on my side)