XSF Discussion - 2020-03-13

This is not just their problem. If the US (or any other country, for that matter) gets hit hard, the rest of us will feel that too. Individual countries cannot stop this. Not medically, not socially, not economically.

But we can send latex gloves, size XXS

What I personally don't like is that the experienced Taiwan offered their help, but they (WHO & e.g. EU) refused. Still they expect everyone to listen to their too late recommendations in terms of how quickly Taiwan reacted to everything.

MUC hats format bikeshedding, commence: <hat uri="urn:example:foo" label="My Awesome Hat" />

e.g. do we need xml:lang?

and do we need multiple labels with different xml:lang?

or is that something we agreed we should move away from?

I guess it's less of a problem when the xep is very clear about that and all implementors now that from the beginning

I still don't like xml:lang very much. But if enums are not an option I don't see a way around them either

MattJ, let's say we use the language of the room?

That can be multiple :p

At which point I'd say there should just be a single label

Can we render older version of a XEP with https://xmpp.org/extensions? I'm checking OMEMO but I need last iteration (0.3) as there were massive changes in last one.

hmm there should be

seems 0.3 is not in the attic

I can still do it manually from the repos, but it would be handy to be able to check it from there.

https://xmpp.org/extensions/attic/xep-0384-0.2.html that's what the url looks like.

But 0.3 is 404, let me see..

https://xmpp.org/extensions/attic/xep-0384-0.3.0.html

that's because I included the .0

Some have it some don't :x

pep.: great thanks!

MattJ, hats?

-v please

Hats!

I’d say xml:lang labels and use references (or something similar but saner) to mark up the "mention" of the hat?

(if hats are like the teams protoxep draft I have uncommitted in my ~/xeps)

Extended affiliations kinda

like @iteam?

Mebbe

are hats centrally managed or self-assigned?

It Depends

if self-assigned, how to avoid slightly different "keys" (be it URIs or labels) from breaking a team formation?

Have a pep node of all existing hat names? Mandate client side auto completion?

the latter is clear, but who’d host the pep node?

the MUC service?

or the MUC room?

hm, service-wide hats and per-room hats?

I imagine the most often it'll be managed by something more central

I'd want xml:lang tbh. maybe it <hat xmlns="urn:example:foo"><label /></hat> ? and allow multiple labels. In pratice it will mostly be one, but it doesn't cost you much ✏

make it*

agreed on xml:lang

and there I was implementing a single label (+ optional xml:lang)

> 19:29:39 jonas’> if self-assigned, how to avoid slightly different "keys" (be it URIs or labels) from breaking a team formation? I don't understand the question

afk now

MattJ: I suppose it's about one member having a "gray" hat and another one a "grey"

🥁️

Hats are defined by the service/room, and use URIs