-
flow
pep., actually a pretty popular part of openfire and smack
-
flow
(and I guess spark)
-
pep.
https://github.com/xsf/xmpp.org/pull/588 hmm.
-
pep.
Is there something saying it must be somebody involved with the projects?
-
Ge0rG
I'm saying that
-
pep.
I also think it makes sense to say that
-
Ge0rG
https://xmpp.org/2017/03/new-xmpp-software-listing-rules/
-
Ge0rG
> the XSF Board has decided that all implementations have to reapply once per year
-
Ge0rG
It's not an explicit "nobody else may do it for you" but I still think the wording is clear
-
flow
so who wants to tell him that the spend those two hours in vain?
-
pep.
We can keep the link updates :)
-
flow
true
-
Ge0rG
we can kindly ask them to contact individual project maintainers and to ACK the PR
-
Ge0rG
that would only take another two hours or so
-
jonas’
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.
-
Ge0rG
jonas’: there are always fans caring enough about their abandoned pet project of xmpp client. This is a very slippery slope to move forward
-
flow
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
-
Guus
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
-
Guus
I'm fine with the required level of activity not being formally defined.
-
Guus
Also: workgroup queues is indeed a popular part of the IgniteRealtime projects. I think the XEP was authored by Jive, at the time.
-
Guus
I'd consider adopting it, if there's momentum.
-
Daniel
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
-
Daniel
I kinda get where this activity thing is coming from. But apparently it's not stopping Pidgin from getting listed anyway
-
flow
well the goal was to hide abandoned projects and pidgin appears to be actively developed ( https://bitbucket.org/pidgin/main/commits/all )
-
pep.
The XMPP part of pidgin* ?
-
Daniel
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
-
pep.
I guess it's more or less easy for a multi-protocol client to show activity
-
Daniel
But in reality it's a pretty flawed one
-
Daniel
As my hypothetical example with pidgin and Conversations a year from now pointed out
-
Zash
Having at least one developer that remembers to do the renewal once per year*
-
pep.
Zash, poezio just got reminded by one of its users :p
-
Zash
!= actively developed
-
pep.
jonas’, one more click plz, https://github.com/xsf/xmpp.org/pull/591/files :)
-
jonas’
done
-
pep.
o/
-
pep.
I'm looking at Meetups listed on the events page and I'm curious about Paris, there was one in the past right?
-
pep.
nyco, Link Mauve, ^
-
ralphm
Guus: if it is actively being used, maybe that XEP should be revived?
-
kockblock
XMPeePee is PooPoo
-
kockblock
Oh, Daniel der Lutsch ist auch hier
-
ralphm
Bye!
-
Lance
Has anyone used MUC hats to build anything? https://xmpp.org/extensions/xep-0317.html
-
Guus
Physical hats, but that's not what you mean.
-
Lance
Looking at using it for a work project to implement discord style room roles/permissions.
-
ralphm
Mostly an obscure cult, so far.
-
ralphm
But yes, I still think the idea is solid.
-
ralphm
It was also designed with games in mind.
-
lovetox
yeah looks good
-
lovetox
but do i read this corectly the server adds the hat to the presence?
-
Lance
Heh, "format is open for debate" with three possible options. But I think option 1 is the one to go with.
-
Lance
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
-
ralphm
I drafted this with hildjj in the FOSDEM hackers room many moons ago.
-
lovetox
yeah looks like a nice idea, easy to implement for clients
-
lovetox
but mostly server work
-
ralphm
Would be happy to be the author to revive.
-
lovetox
so yeah i definitly would implement that in gajim if a server has support
-
Lance
I'll have implementation experience to provide over the next few weeks then ralphm
-
lovetox
Gajim also has the necessary adhoc interface for the admins
-
ralphm
Cool.
-
ralphm
Lance: let me know when, and we'll pick it up
-
ralphm
There are a few, eh, sparse sections.
-
Lance
lmao, yes. that's what prompted my asking :)
-
Seve
Lance: check converse.js
-
lovetox
ah i wondered what this tags are
-
lovetox
but this is weird how can converse.js show this if servers dont have support for it
-
pep.
Lance, I think MattJ and jc were interested in hats
-
wurstsalat
This was also on a sprint's agenda some time ago
-
pep.
Yeah it was discussed somewhat in Cambridge, I don't think anything came out of it though
-
Lance
ah, wonderful, gajim supports adhoc commands on rooms. that makes testing hats so much easier now
-
pep.
Prosody doesn't support ad-hoc on rooms iirc :(
-
Lance
... of course not. will still give it a try, trunk might surprise me
-
Lance
but i at least have a module now that will strip out hats sent by occupants, and stamp the hats assigned by the server
-
Zash
Lance: Already? Nice.
-
MattJ
I have a module that does... something
-
Lance
Zash: check the presence stanzas in the stanza discuss room :p
-
MattJ
Would have to check when I'm at my laptop
-
Zash
pep.: It should be doable to re-use the adhoc(.lib) handling itself and adapt it to MUC.
-
ralphm
😃🍿
-
MattJ
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
-
Zash
The only certainty is that the one with the most hats wins!
-
Zash
Hat Fortress 2 over XMPP! \o/
-
ralphm
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.
-
ralphm
Not sure how easy it is to make this generic.
-
lovetox
i thought this is simply something the room owner decides
-
MattJ
iirc I made a generic module that could be extended for different use cases
-
lovetox
like promoting someone to moderator, i can give him a hat
-
Lance
Or in my case, with audio/video conferencing, who is allowed to stream :)
-
MattJ
lovetox: decides how/where? Where does the list of hats come from?
-
Zash
Implementing such logic in a bot seems logical
-
ralphm
lovetox: what I mean is that if you have a hat 'chair person', you probably want a rule that there can be only one.
-
ralphm
Codifying rules like this generically is hard.
-
MattJ
Yeah, that
-
lovetox
Of course you can think up all rules, but i think also just the admin thinking up some hat like "Teacher" is already fine
-
ralphm
And I think such rules are business logic and application specific and should be in _this_ XEP.
-
lovetox
i show the label as client beside the nick
-
lovetox
and thats it
-
lovetox
everybody knows this is the teacher :)
-
Zash
Custom MUC modules/server-side extensions?
-
ralphm
If you want to expose rooms with the rule 'do whatever you want', then yeah, that's pretty easy to do.
-
MattJ
lovetox: hats are namespaced, and for a reason... you might want to allow PMs to teachers but not other students, etc.
-
MattJ
So the label is just a part of it
-
ralphm
The label is the least interesting part of hats.
-
fippo
lance: so you're doing stuff we discussed in... 2015? :-)
-
lovetox
Ok i understand you can treat hats like roles with permissions
-
MattJ
And if a student makes a room and assigns themselves 'Teacher', that is unacceptable in many cases :)
-
lovetox
but you could also just display the label
-
lovetox
its already useful
-
Lance
fippo: yes
-
Lance
i've kinda put a lot of things on backburner for a few years
-
MattJ
Sure, just displaying the label is fine
-
lovetox
Yes i understand you could add lots of nice features on top of that
-
fippo
lance: problems put on the backburner are much more tasty :-)
-
MattJ
fippo: or the smoke alarm goes off
-
ralphm
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.
-
ralphm
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.
-
Zash
This sounds a lot like security labels
-
Lance
Yeah, it kinda is. Security labels for occupants, not messages
-
lovetox
a bit but not really
-
lovetox
sec labels are about messages
-
lovetox
though the part who is allowed to put labels onto messages could be also a hat
-
Zash
In the more general sense that all the interesting logic would resid on the server side, with the protocol mostly being about presentation
-
ralphm
Right
-
Lance
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
-
ralphm
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.
-
Lance
Or a query that returns the somehow-compiled set of what you're allowed to do, based on your current hats.
-
ralphm
Such basic protocol might be part of this XEP even.
-
ralphm
And we'd it clear how one might use hats in MIX, which lacks roles
-
ralphm
make
-
ralphm
For MUC, roles and affiliations could be grandfathered in
-
MattJ
Lance: ping me tomorrow if you're around, I definitely already have stuff around this, I just don't remember how complete it was
-
MattJ
I was planning to update the XEP
-
Lance
Will do MattJ. Thanks!
-
ralphm
I'll give it some sleep, too