XSF Discussion - 2019-07-17

pep., actually a pretty popular part of openfire and smack

(and I guess spark)

https://github.com/xsf/xmpp.org/pull/588 hmm.

Is there something saying it must be somebody involved with the projects?

I'm saying that

I also think it makes sense to say that

https://xmpp.org/2017/03/new-xmpp-software-listing-rules/

> the XSF Board has decided that all implementations have to reapply once per year

It's not an explicit "nobody else may do it for you" but I still think the wording is clear

so who wants to tell him that the spend those two hours in vain?

We can keep the link updates :)

true

we can kindly ask them to contact individual project maintainers and to ACK the PR

that would only take another two hours or so

I think the consensus back then was "if someone cares enough", not necessarily involved with the project. In this case, they went through the trouble to hunt down releases and stuff, so maybe it’s worth letting them do the renew.

jonas’: there are always fans caring enough about their abandoned pet project of xmpp client. This is a very slippery slope to move forward

As long as we don't have system in place where only registered e-mail/xmpp addresses of the project are able to update the entry, I would be willing to take that slippery slope

The though behind the renewal is to have a more or less up to date listing, not to have direct engagement with individual projects. I'd not object to third party contributions, when the contributed-to project shows some relevant activity

I'm fine with the required level of activity not being formally defined.

Also: workgroup queues is indeed a popular part of the IgniteRealtime projects. I think the XEP was authored by Jive, at the time.

I'd consider adopting it, if there's momentum.

It's all problematic anyway. If I were to stop developing Conversations now it's probably still going to be a relatively decent xmpp client in a year

I kinda get where this activity thing is coming from. But apparently it's not stopping Pidgin from getting listed anyway

well the goal was to hide abandoned projects and pidgin appears to be actively developed ( https://bitbucket.org/pidgin/main/commits/all )

The XMPP part of pidgin* ?

The goal was to have a decent list of recommendations without getting too political. And activity was the seemingly objective criteria we came up with as the lowest common denominator

I guess it's more or less easy for a multi-protocol client to show activity

But in reality it's a pretty flawed one

As my hypothetical example with pidgin and Conversations a year from now pointed out

Having at least one developer that remembers to do the renewal once per year*

Zash, poezio just got reminded by one of its users :p

!= actively developed

jonas’, one more click plz, https://github.com/xsf/xmpp.org/pull/591/files :)

done

o/

I'm looking at Meetups listed on the events page and I'm curious about Paris, there was one in the past right?

nyco, Link Mauve, ^

Guus: if it is actively being used, maybe that XEP should be revived?

XMPeePee is PooPoo

Oh, Daniel der Lutsch ist auch hier

Bye!

Has anyone used MUC hats to build anything? https://xmpp.org/extensions/xep-0317.html

Physical hats, but that's not what you mean.

Looking at using it for a work project to implement discord style room roles/permissions.

Mostly an obscure cult, so far.

But yes, I still think the idea is solid.

It was also designed with games in mind.

yeah looks good

but do i read this corectly the server adds the hat to the presence?

Heh, "format is open for debate" with three possible options. But I think option 1 is the one to go with.

Yeah, first step for me will be making a prosody module that strips out any hats a user tries to send themselves, and stamp the correct server-sanctioned ones

I drafted this with hildjj in the FOSDEM hackers room many moons ago.

yeah looks like a nice idea, easy to implement for clients

but mostly server work

Would be happy to be the author to revive.

so yeah i definitly would implement that in gajim if a server has support

I'll have implementation experience to provide over the next few weeks then ralphm

Gajim also has the necessary adhoc interface for the admins

Cool.

Lance: let me know when, and we'll pick it up

There are a few, eh, sparse sections.

lmao, yes. that's what prompted my asking :)

Lance: check converse.js

ah i wondered what this tags are

but this is weird how can converse.js show this if servers dont have support for it

Lance, I think MattJ and jc were interested in hats

This was also on a sprint's agenda some time ago

Yeah it was discussed somewhat in Cambridge, I don't think anything came out of it though

ah, wonderful, gajim supports adhoc commands on rooms. that makes testing hats so much easier now

Prosody doesn't support ad-hoc on rooms iirc :(

... of course not. will still give it a try, trunk might surprise me

but i at least have a module now that will strip out hats sent by occupants, and stamp the hats assigned by the server

Lance: Already? Nice.

I have a module that does... something

Zash: check the presence stanzas in the stanza discuss room :p

Would have to check when I'm at my laptop

pep.: It should be doable to re-use the adhoc(.lib) handling itself and adapt it to MUC.

😃🍿

I think the hardest part of hats is knowing who should be able to wear them and when, and of course that isn't in the XEP and varies across deployments

The only certainty is that the one with the most hats wins!

Hat Fortress 2 over XMPP! \o/

Yeah, the assumption was that the rooms would have business for that. Like if you expose a chess game as a MUC room, it would know what hats are appropriate.

Not sure how easy it is to make this generic.

i thought this is simply something the room owner decides

iirc I made a generic module that could be extended for different use cases

like promoting someone to moderator, i can give him a hat

Or in my case, with audio/video conferencing, who is allowed to stream :)

lovetox: decides how/where? Where does the list of hats come from?

Implementing such logic in a bot seems logical

lovetox: what I mean is that if you have a hat 'chair person', you probably want a rule that there can be only one.

Codifying rules like this generically is hard.

Yeah, that

Of course you can think up all rules, but i think also just the admin thinking up some hat like "Teacher" is already fine

And I think such rules are business logic and application specific and should be in _this_ XEP.

i show the label as client beside the nick

and thats it

everybody knows this is the teacher :)

Custom MUC modules/server-side extensions?

If you want to expose rooms with the rule 'do whatever you want', then yeah, that's pretty easy to do.

lovetox: hats are namespaced, and for a reason... you might want to allow PMs to teachers but not other students, etc.

So the label is just a part of it

The label is the least interesting part of hats.

lance: so you're doing stuff we discussed in... 2015? :-)

Ok i understand you can treat hats like roles with permissions

And if a student makes a room and assigns themselves 'Teacher', that is unacceptable in many cases :)

but you could also just display the label

its already useful

fippo: yes

i've kinda put a lot of things on backburner for a few years

Sure, just displaying the label is fine

Yes i understand you could add lots of nice features on top of that

lance: problems put on the backburner are much more tasty :-)

fippo: or the smoke alarm goes off

For more generic rooms, you could start with allowing room admins to assign hats. Another would be a mechanism that allows room admins to whitelist members per hat they can assume.

E.g. in this room, a whitelist of Directors could assume a hat that means Chair. Usually that would be me, sometimes Alex, sometimes another person in my absence.

This sounds a lot like security labels

Yeah, it kinda is. Security labels for occupants, not messages

a bit but not really

sec labels are about messages

though the part who is allowed to put labels onto messages could be also a hat

In the more general sense that all the interesting logic would resid on the server side, with the protocol mostly being about presentation

Right

So next round of iteration for this for me is probably going to be adding permissions to hats. So some way to query a hat to get back a dataform of what's allowed or not. That _might_ inform some updates for the xep

I can imagine some form of useful, but limited, hat admin protocol. If you then want more fancy, you'd do custom oob admin/logic.

Or a query that returns the somehow-compiled set of what you're allowed to do, based on your current hats.

Such basic protocol might be part of this XEP even.

And we'd it clear how one might use hats in MIX, which lacks roles

make

For MUC, roles and affiliations could be grandfathered in

Lance: ping me tomorrow if you're around, I definitely already have stuff around this, I just don't remember how complete it was

I was planning to update the XEP

Will do MattJ. Thanks!

I'll give it some sleep, too