XSF Discussion - 2023-06-28

https://www.rfc-editor.org/info/rfc9413 Maintaining Robust Protocols Might be worth a look when I'm awake.

edhelas, IIRC you were interested in hats: https://github.com/xsf/xeps/pull/1285

MattJ 💕

Cool!

Now lets implement that in XMPP servers :3 !

https://hg.prosody.im/0.12/file/tip/plugins/muc/hats.lib.lua :)

Looks like I'll have to open a ticket for ejabberd ?

IIRC someone told me they were implementing the same syntax

"someone"

The real question (not addressed by this XEP update) is exactly how hats get assigned

To me something like like "only admins/owners" can do it seems doable. And then you let bots taking care of it.

why bots?

Discord is doing it this way, and it leaves all the complexity to the implementers.

edhelas, who defines the hats?

Well admins as well ?

Then we need some kind of protocol for that

Time to do PEP over MUC :3 ?

<iq type='set' to='xsf@muc.xmpp.org' id='publish1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <publish node='urn:xmpp:hats:0'> <item id='host'> <hat title='Host' uri='http://schemas.example.com/hats#host' xml:lang='en-us'> <badge xmlns="urn:example:badges" fgcolor="#000000" bgcolor="#58C5BA" /> </hat> </item> </publish> </pubsub> </iq>

> Then we need some kind of protocol for that I have a protocol for you ;) ↺

Of course :)

really colors?

lovetox, it's a common aspect of this feature in other platforms, so yeah

and they can define the colors themself?

as in the user

but i guess why not

so whats the idea, to store the metadata like color somewhere else, and only send a reference in the presence?

ah no its in the presence

so why pubsub?

to store what hats are allowed in a room? ✏

Yes

We might have a specific namespaces for colors

So it can be reused in other XEPs, Hats might not be the only case where we might need it

sounds overengineered, security labels use colors since forever

why the uris?

whats the idea behind that?

maybe i missed it, but there is no flow to remove a hat

The URIs allow uniquely identifying a hat

the title does also

or lets say it could

No, because the title might be translated, for example

haha

would be a first

who does the translating ? the Admin?

Doesn't matter

in what situation do i need to identify a hat by its uri?

You don't *need* to, which is why there is a title

Clients can just ignore the URI for display purposes, and render the title

But they may understand the URI, and apply some special meaning

its more and more like a security label for presence

Maybe, I can see similarities

has a label/uri which we can ignore, and a displaymarking/title/color which we display :D

presence is of course a problem

should you not go full security label, and attach the hat to the message?

i mean the server

otherwise MAM etc will be a problem

Then how would you discover the hats of people who haven't written a message?

maybe additional?

not instead

Sure, possibly

We have occupant-id and stuff for that though already, right?

hmmm .. meh thats a can of worms

so i receive presence, and then attach a hat retroactively to past messages i receive?

nah it should be independent of presence in my opinion

Hats are associated with users, not messages

Think of them as extended affiliations

are affiliations not added to MUC MAM messages?

I don't think so?

examples in the MAM XEP sure look like it

> In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in Multi-User Chat (XEP-0045) [11]. Indeed.

if you only add it to presence, my GUI would only add it to the roster

MUC roster is mostly hidden for most users

When i read about the XEP i thought, ok i add a "Teacher" badge to each message

because so people know the messages comes from the Teacher

So my GUI would attach hats to messages

don’t know how other im solutions use hats

if its just a "user can look it up if he wants in the roster" kind of thing, i would not find it that useful

Also this attaching it to messages makes it more flexibel, when presence is not broadcasted, for example big MUCs

And then it would be a security label without the security :D

the diff is subtle, with sec labels i can add different to each message, which would not be the case here