XSF Discussion - 2019-07-17


  1. flow

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

  2. flow

    (and I guess spark)

  3. pep.

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

  4. pep.

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

  5. Ge0rG

    I'm saying that

  6. pep.

    I also think it makes sense to say that

  7. Ge0rG

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

  8. Ge0rG

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

  9. Ge0rG

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

  10. flow

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

  11. pep.

    We can keep the link updates :)

  12. flow

    true

  13. Ge0rG

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

  14. Ge0rG

    that would only take another two hours or so

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

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

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

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

  19. Guus

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

  20. Guus

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

  21. Guus

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

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

  23. Daniel

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

  24. flow

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

  25. pep.

    The XMPP part of pidgin* ?

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

  27. pep.

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

  28. Daniel

    But in reality it's a pretty flawed one

  29. Daniel

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

  30. Zash

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

  31. pep.

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

  32. Zash

    != actively developed

  33. pep.

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

  34. jonas’

    done

  35. pep.

    o/

  36. pep.

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

  37. pep.

    nyco, Link Mauve, ^

  38. ralphm

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

  39. kockblock

    XMPeePee is PooPoo

  40. kockblock

    Oh, Daniel der Lutsch ist auch hier

  41. ralphm

    Bye!

  42. Lance

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

  43. Guus

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

  44. Lance

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

  45. ralphm

    Mostly an obscure cult, so far.

  46. ralphm

    But yes, I still think the idea is solid.

  47. ralphm

    It was also designed with games in mind.

  48. lovetox

    yeah looks good

  49. lovetox

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

  50. Lance

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

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

  52. ralphm

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

  53. lovetox

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

  54. lovetox

    but mostly server work

  55. ralphm

    Would be happy to be the author to revive.

  56. lovetox

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

  57. Lance

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

  58. lovetox

    Gajim also has the necessary adhoc interface for the admins

  59. ralphm

    Cool.

  60. ralphm

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

  61. ralphm

    There are a few, eh, sparse sections.

  62. Lance

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

  63. Seve

    Lance: check converse.js

  64. lovetox

    ah i wondered what this tags are

  65. lovetox

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

  66. pep.

    Lance, I think MattJ and jc were interested in hats

  67. wurstsalat

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

  68. pep.

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

  69. Lance

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

  70. pep.

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

  71. Lance

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

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

  73. Zash

    Lance: Already? Nice.

  74. MattJ

    I have a module that does... something

  75. Lance

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

  76. MattJ

    Would have to check when I'm at my laptop

  77. Zash

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

  78. ralphm

    😃🍿

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

  80. Zash

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

  81. Zash

    Hat Fortress 2 over XMPP! \o/

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

  83. ralphm

    Not sure how easy it is to make this generic.

  84. lovetox

    i thought this is simply something the room owner decides

  85. MattJ

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

  86. lovetox

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

  87. Lance

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

  88. MattJ

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

  89. Zash

    Implementing such logic in a bot seems logical

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

  91. ralphm

    Codifying rules like this generically is hard.

  92. MattJ

    Yeah, that

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

  94. ralphm

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

  95. lovetox

    i show the label as client beside the nick

  96. lovetox

    and thats it

  97. lovetox

    everybody knows this is the teacher :)

  98. Zash

    Custom MUC modules/server-side extensions?

  99. ralphm

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

  100. MattJ

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

  101. MattJ

    So the label is just a part of it

  102. ralphm

    The label is the least interesting part of hats.

  103. fippo

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

  104. lovetox

    Ok i understand you can treat hats like roles with permissions

  105. MattJ

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

  106. lovetox

    but you could also just display the label

  107. lovetox

    its already useful

  108. Lance

    fippo: yes

  109. Lance

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

  110. MattJ

    Sure, just displaying the label is fine

  111. lovetox

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

  112. fippo

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

  113. MattJ

    fippo: or the smoke alarm goes off

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

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

  116. Zash

    This sounds a lot like security labels

  117. Lance

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

  118. lovetox

    a bit but not really

  119. lovetox

    sec labels are about messages

  120. lovetox

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

  121. Zash

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

  122. ralphm

    Right

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

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

  125. Lance

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

  126. ralphm

    Such basic protocol might be part of this XEP even.

  127. ralphm

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

  128. ralphm

    make

  129. ralphm

    For MUC, roles and affiliations could be grandfathered in

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

  131. MattJ

    I was planning to update the XEP

  132. Lance

    Will do MattJ. Thanks!

  133. ralphm

    I'll give it some sleep, too