XSF Discussion - 2023-05-16


  1. pep.

    Is it too late to add a urn:xmpp:blocking#muc that says "Can also be applied to MUC occupants by adding an @occupant containing an occupant-id to <item/>"? It's stable.

  2. MattJ

    Is the intent that the user's server would track occupants in remote MUCs, or how would it work?

  3. pep.

    hmm. Maybe this should be its own spec and be stored on the MUC rather

  4. pep.

    hmm. Maybe this should be stored on the MUC rather

  5. pep.

    Different spec then? With a protocol somewhat similar to blocking?

  6. Zash

    Block command to the room?

  7. pep.

    Yeah

  8. MSavoritias (fae,ve)

    isnt that already there? or is conversations misusing the feature?

  9. pep.

    It's probably an implementation detail of servers that make this work

  10. pep.

    "work"

  11. pep.

    Blocking a nick isn't the same as blocking an occupant-id

  12. MSavoritias (fae,ve)

    ah right. occupant-id is only on the server?

  13. pep.

    It tracks JIDs in a room (pseudonymous, still)

  14. MSavoritias (fae,ve)

    right

  15. pep.

    Whereas just using nicks can lead to blocking someone that has nothing to do with the original person that was blocked

  16. MSavoritias (fae,ve)

    i wonder how you would do this on mix /thinking

  17. MSavoritias (fae,ve)

    need to read more of the docs ^^'

  18. pep.

    Would it make sense to reuse the 191 NS, or is it forever taken for the 1:1 case?

  19. MattJ

    Probably a question for the current council members, as they would be the ones who would need to approve it

  20. Daniel

    Big picture I would probably prefer if we find a way to put the occupant-id into the resource for everything that's coming from a muc (presence + messages). Then you can continue using regular blocking command

  21. Daniel

    (not wearing a council hat)

  22. Daniel

    Putting unstable Nicks into the resource was a mistake that needs fixing

  23. MattJ

    Indeed, MIX changes that

  24. emus

    PR is open for June release: https://github.com/xsf/xmpp.org/pull/1273+

  25. emus

    PR is open for June release: https://github.com/xsf/xmpp.org/pull/1273

  26. pep.

    MattJ, it doesn't, does it? (humor I did not sense?)

  27. pep.

    Daniel, I think making the resource meaningful here is a mistake fwiw

  28. pep.

    whether for nicks or occupant-id

  29. MattJ

    pep., it does. In MIX, the sending resource is the paricipant ID

  30. pep.

    Ah ok. Yeah it's still an issue to me but it's better than MUC ok

  31. singpolyma

    I think I'm the last person who really likes the design of MUC 😅

  32. pep.

    Can we not redo MUC/MIX after my question please :)

  33. MattJ

    The nice thing about MUC's (currently implemented) approach is that it ensures participant names are unique. Back then it was considered a very desirable (if not essential) feature, to prevent nick spoofing.

  34. MattJ

    Although people now find it weird that you can't have two people with the same name in a chat, you also see "modern" platforms struggle with the "unique name" vs "display name" thing

  35. Kev

    Except for using resourceprep, which is unsuitable for such things ;)

  36. MattJ

    Discord's recent user renaming being an example of that

  37. MattJ

    Of course we don't necessarily need this enforcement at the protocol level, and it may be better as a server feature, that could be toggled on/off depending on the deployment's requirements

  38. MattJ

    There's nothing stopping us from switching to participant ids in MUC resources and using <nick> for display purposes, we'd just have to agree to do it

  39. singpolyma

    Though there are privacy implications to having durable participant IDs so it probably shouldn't become mandatory... I guess the durable part is optional even if the IDs become mandatory

  40. pep.

    Yeah I'd prefer using <nick> too

  41. MattJ

    pep., so what's the plan to prevent impersonation?

  42. singpolyma

    Reservation?

  43. pep.

    Have the MUC do it?

  44. pep.

    Not sure I get the question

  45. MattJ

    So the server enforces uniqueness of <nick> per occupant?

  46. singpolyma

    And enforces Nick only used by owning jid when reservation is present, as now

  47. pep.

    As it's currently ~done, that is with the mess that is MSN etc.

  48. pep.

    That doesn't change much, apart from MUC-PMs, which maybe we can rethink.. or retire, dunno :/

  49. pep.

    Even though MUC-PMs would also be best to occupant-ids / some kind of participant id anyway

  50. singpolyma

    We have basically the opposite problem with pubsub where nodes don't have JIDs at all. Trade offs everywhere

  51. pep.

    singpolyma, do you have an example use-case where participant IDs aren't needed? Or rather harmful?

  52. singpolyma

    pep.: Right now a user can leave the MUC and come back moments later and no one (outside of admin of course) can know it's the same person, especially if they change nick

  53. singpolyma

    With durable participant id that becomes not possible

  54. singpolyma

    Don't get me wrong, I get that usually this is a misfeature. I'm honesty pro non anon for most rooms. But there are definitely cases where people like the privacy properties of semi anon

  55. pep.

    Yeah, this is actually someting occupant-id "solves". I never know where to stand regarding privacy here.

  56. pep.

    This is often a misfeature indeed

  57. MSavoritias (fae,ve)

    is occupant-id specific to muc?

  58. pep.

    I personally prefer anon rooms and this helps

  59. singpolyma

    MSavoritias (fae,ve): yes

  60. pep.

    MSavoritias (fae,ve), yeah

  61. singpolyma

    I mean, it's up to the MUC, but that's the idea

  62. singpolyma

    They make the semi in semi anon much more

  63. pep.

    I'd even go as far as saying I'd like JIDs to disappear from MUC altogether, not even exposed to admins

  64. pep.

    Because they don't need it

  65. pep.

    JIDs can stay in the operator realm

  66. MSavoritias (fae,ve)

    i am interested in paving the way towards burner jids in groupchats too

  67. MSavoritias (fae,ve)

    like fully anon

  68. pep.

    MSavoritias (fae,ve), yeah that's an option I have on my list to study

  69. MSavoritias (fae,ve)

    yeah. of course it brings up questions of how do we handle abuse

  70. pep.

    And that would probably work ok with occupant-id, as changing the JID would renew the ID

  71. singpolyma

    MSavoritias (fae,ve): yes, that's my favourite point in the design space. Use non Anon and if people want/need they use burner jid for full Anon participation

  72. MSavoritias (fae,ve)

    so two seperate group chat types? on top of the non anon already?

  73. MSavoritias (fae,ve)

    sounds like too many

  74. singpolyma

    > yeah. of course it brings up questions of how do we handle abuse The trolls are pretty capable of making new JIDs whenever blocked already, so I'm not sure burners changes much

  75. MSavoritias (fae,ve)

    true. better to make moderation better

  76. singpolyma

    > yeah. of course it brings up questions of how do we handle abuse The trolls are pretty capable of making new JIDs whenever blocked already, so I'm not sure burners changes much

  77. Kev

    > I'd even go as far as saying I'd like JIDs to disappear from MUC altogether, not even exposed to admins That's definitely unpleasant in lots of cases, because when people open a chat to someone they have in their roster, they expect it to be the same chat, regardless of whether it's from a MUC or the roster.

  78. singpolyma

    MSavoritias (fae,ve): define 'better' what do you think we're missing?

  79. pep.

    Kev, that depends on "people"

  80. Kev

    I didn't say all people, but I know from non-trivial amounts of experience that there are people who do.

  81. pep.

    I know some who actually like the distinction 1:1/MUC-PM and.. :/

  82. singpolyma

    Kev: right, for sure, I'd never show my family a semi anon room. It's a unique feature to XMPP that's quite unfamiliar

  83. Kev

    > I know some who actually like the distinction 1:1/MUC-PM and.. :/ You mean you have users who *want* to have two chats between the same two people, and it's not just because of a lack of threading support? What's their use case?

  84. pep.

    Anyway there can be a way to negociate giving each other's JIDs

  85. pep.

    They just don't need to be exposed by default

  86. MSavoritias (fae,ve)

    > I know some who actually like the distinction 1:1/MUC-PM and.. :/ I do. But implemented differently

  87. pep.

    Kev, different context, different discussions

  88. MSavoritias (fae,ve)

    Temporary rooms with burner jids that self destructed after a bit :)

  89. pep.

    I'm not one of these people, I don't know

  90. MSavoritias (fae,ve)

    > MSavoritias (fae,ve): define 'better' what do you think we're missing? In group chat context i would like to see more granural permissions implemented. Also a timeout both when a user joins and generally. Also a way to restrict what each user can send based on how much they have been in the chat. Also blocking to actually work. That started this whole discussion :P These aae some stuff of the top of my head

  91. MSavoritias (fae,ve)

    Granted a lot of stuff is there just not implemented. Like hats

  92. MSavoritias (fae,ve)

    Or the accept the tos before you join

  93. emus

    Dear XMPP folks, I know I have been criticized for my insisting concerns on the XEP Editorial situation (no blame on the folks taking efforts over since then). But I still believe that we still have a general ongoing problem here. I hope this statistic below can show a bit the trend. _Two annotations: Dec & January are joined information that explains for example the big 01 2023 spike. And remind Dep, Def and Obs are not included as they misguide actual activity I believe. Anyway the complete data can be accessed and edited yourself via those files:_

  94. singpolyma

    MSavoritias (fae,ve): for timeout you mean "grin permissions over time" kind of thing as an option?

  95. singpolyma

    For "what they can send" you mean restricting media or other things?

  96. singpolyma

    Blocking to "actually work" is a trade off vs anonymity but I agree there is a slider there

  97. emus

    hmm the files got never sent by dino :-*

  98. emus

    hmm the files got never sent by dino :-(

  99. emus

    https://jabbers.one:5281/file_share/2IrQxf3rlCeLVoce3UXZw5My/20230516_150419347_b914..jpg

  100. emus

    hehe we go

  101. emus

    I can sent the data files later

  102. MattJ

    emus, sorry, but I don't see any problem (apart from the fact that a bunch of updates were batched together)

  103. Kev

    It is true that I'm not getting through stuff as quickly as I'd like, but I'm not sure what that graph is implied to be saying.

  104. emus

    > Kev: > 2023-05-16 03:12 (GMT+02:00) > It is true that I'm not getting through stuff as quickly as I'd like, but I'm not sure what that graph is implied to be saying. Its not about your work or so

  105. MattJ

    27 XEPs were published/updated in the first 4 months of this year, compared with 30 XEPs in the first 4 months of last year

  106. MattJ

    a difference of 3 XEPs over a 4 month period with a graph this spiky, is just noise

  107. theTedd

    emus, I don't think you're criticised (personally) it's more that you appear to be focusing on the thing you find easier to quantify, rather than the real reasons which are much less tangible; i.e. if the 'editor situation' were magically fixed, there wouldn't suddenly be a flurry of activity and new XEPs appearing

  108. Kev

    It's not clear to me that there's an Editor issue that's stopping e.g. new XEPs being published.

  109. emus

    > theTedd: > 2023-05-16 03:14 (GMT+02:00) > emus, I don't think you're criticised (personally) it's more that you appear to be focusing on the thing you find easier to quantify, rather than the real reasons which are much less tangible; i.e. if the 'editor situation' were magically fixed, there wouldn't suddenly be a flurry of activity and new XEPs appearing Sure, but we did before in this time hit a month with 0 activity besides I need to fix the chart in the last two months

  110. MattJ

    emus, there was not 0 activity, there were 0 emails sent out

  111. MattJ

    Possibly 0 merges, but I don't think that was the case

  112. emus

    And there have been compliants from others too. and its also a bit unclear if we manage to get a basic automated setup at some spot?

  113. MattJ

    You just posted a graph that shows there has been no substantial change

  114. MattJ

    Whether stuff is sufficiently automated is up to the people doing editor work

  115. MattJ

    I'm not sure what more there is to discuss

  116. theTedd

    there are countless reasons why people are otherwise busy or distracted, and it changes wildly over time; editing harder won't change that

  117. Kev

    I'm sure if there's a queue of people who're wanting to do Editor work that I'm not knowingly turning them away.

  118. emus

    Kev: Its a general concern. I see that you jumped in and now trying to get it right. but I think thats not where we want to be with our core business, right? I should be fully backed in the organisation rather having more people or automation serving this? Besides jonas listed a lot of concerns to be adressed back in September, but I am not sure if we are out of risk that this cannot happen again, right?

  119. Kev

    (And if someone would like to take on the role entirely, I'd very much not be sad about not having that pressure)

  120. emus

    > Kev: > 2023-05-16 03:25 (GMT+02:00) > (And if someone would like to take on the role entirely, I'd very much not be sad about not having that pressure) yes, this ^ for example

  121. Alex

    A reminder that our current application period ends soon, in case you need to reapply: https://wiki.xmpp.org/web/Membership_Applications_Q2_2023

  122. emus

    Kev: I assume this is rather at the lower end of our resources. we shouldnt act there

  123. emus

    Thanks alex

  124. Kev

    Re: Automation, moparisthebest (Please let me not have misremembered) wrote a triage checker for individual PRs. I have written on top of that a checker for the PR queue as a whole that works through each in turn running the script and telling me what to do - it doesn't get things 100% right (largely because of noisy data), so I don't think integrating it into the pipeline is right at the moment, but it's already being a significant help. I've also written scripts that wrap the PR queue script to manage the whole of a XEP Editor session, from PR checking through to sending mails (with the script I suspect Jonas originally wrote), uploading and deploying new images/containers. So things aren't perfect, but they're significantly better (in my view) than when Jonas retired.

  125. emus

    But shouldnt we then try to get them into the pipeline and call for an "official" Editor (unless you & peter want to continue) to leave the "emergency staffing" (as I understood)

  126. emus

    > theTedd: > 2023-05-16 03:14 (GMT+02:00) > rather than the real reasons which are much less tangible but what are the real reasons? sure I just pulled the data and see whats in there

  127. theTedd

    > there are countless reasons why people are otherwise busy or distracted, and it changes wildly over time; editing harder won't change that

  128. MSavoritias (fae,ve)

    > MSavoritias (fae,ve): for timeout you mean "grin permissions over time" kind of thing as an option? Yeah. So a mod can "pause" a person from sending some specific type of thing and a person cant flood a roomwith stuff when they join. Instead you have a rule saying messages after 2 hours, images after 3 days and so on.

  129. MSavoritias (fae,ve)

    Also for granular permission i meant that its only mod and no mod. But a more granural thing. So hats basically. But deployed.

  130. theTedd

    eXtended Moderation Permissions Policy

  131. cal0pteryx (wurstsalat)

    but instead of trying to keep the status quo, shouldn't we aim to improve the situation even more? so that for example the backlog of PRs (40 atm) would get smaller over time?

  132. MattJ

    Are those 40 PRs requiring editor attention?

  133. Zash

    Group by "needs $who" ?

  134. cal0pteryx (wurstsalat)

    are people other than the editor actually maintain the PR list?

  135. cal0pteryx (wurstsalat)

    are people other than the editor actually maintaining the PR list?

  136. MSavoritias (fae,ve)

    Or make the tooling/architecture simpler and documented

  137. MSavoritias (fae,ve)

    Which from what i get is already a goal kind of

  138. theTedd

    Editor Tooling Sprint!

  139. MSavoritias (fae,ve)

    XEP process sprint 😁

  140. cal0pteryx (wurstsalat)

    > XEP process sprint 😁 that, too. the oldest PR dates back to 2017, and there are several other old/abandoned PRs

  141. emus

    > MSavoritias (fae,ve): > 2023-05-16 03:55 (GMT+02:00) > XEP process sprint 😁 actually why not

  142. MSavoritias (fae,ve)

    I said xep process because there were some ideas floating around to improve the xep submission process itself

  143. MSavoritias (fae,ve)

    One of them being not having to vote for experimental xeps and making tbe council gatekeepers in the process

  144. MSavoritias (fae,ve)

    Which i would be very much in favor

  145. MSavoritias (fae,ve)

    >> XEP process sprint 😁 > that, too. the oldest PR dates back to 2017, and there are several other old/abandoned PRs Yep. Good point

  146. theTedd

    sprints should be limited in scope, just to maintain focus

  147. MSavoritias (fae,ve)

    Well i see them connected. 🤷

  148. theTedd

    there's no reason both couldn't be done, I just meant it's best not to try to do too much under one umbrella

  149. theTedd

    XEPs should have some basic 'quality checks' but there's no reason that must necessarily be done by Counicl

  150. theTedd

    *Council (but then who?)

  151. moparisthebest

    Kev: I tried to clean up the noisy data here, can we get that merged? It's never going to pass CI https://github.com/xsf/xeps/pull/1265

  152. moparisthebest

    (because ci requires things we don't wanna do there)

  153. MSavoritias (fae,ve)

    > XEPs should have some basic 'quality checks' but there's no reason that must necessarily be done by Counicl For experimental? Sure. But those are already done. Council doesnt need to intervene there

  154. MSavoritias (fae,ve)

    With the github ci that is

  155. Kev

    > (because ci requires things we don't wanna do there) Could you leave that motivation on the PR so I'll see it next time I do a pass, please?

  156. Kev

    I'll remove 'needs changes' so I'll hopefully look at it again.

  157. moparisthebest

    Kev: when I say "we don't want to do" I'm wildly assuming you don't want to actually release new versions for each of those just to add missing but implied data :D sure I'll write it down

  158. Kev

    Sure, that argument's compelling.

  159. Kev

    And thanks.

  160. jjrh

    > Openfire has a very old plugin for Asterisk integration, but I'm not exactly sure if a) it's still functional and b) what exacty its features are. We could have a look at reviving it, if you're interested. The big problem with asterisk xmpp if I remember correctly is that it requires you have someone's jid/password which is obviously silly.

  161. singpolyma

    jjrh: how do you mean? We use the asterisk xmpp stuff

  162. jjrh

    Last I looked you had to configure every account you want to support.

  163. Zash

    Like with gateways/transports?

  164. jjrh

    So if you want to do something like map sipsimple to xmpp you need that extensions jid and password. When what you really want is asterisk acting as a component server.

  165. jjrh

    I don't think jingle works at all for asterisk anymore at least not in a useful way.

  166. moparisthebest

    jjrh: https://sip.cheogram.com/ ?

  167. jjrh

    Oh neat. Are you trying to get that merged upstream?

  168. moparisthebest

    That's a singpolyma question

  169. jjrh

    You forked asterisk and wrote a module or are you just translating sip to jingle?

  170. singpolyma

    Asterisk does all the heavy lifting for sip to jingle

  171. singpolyma

    I wrote a wrapper to do things like JMI

  172. singpolyma

    and better JIDs, etc

  173. jjrh

    So it's just using mod_jingle in asterisk?

  174. singpolyma

    There is a minor asterisk fork needed for DTLS also. We're not actively trying to merge it upstream due to the CLA

  175. singpolyma

    it's not called mod_jingle, but whatever the jingle module is called yeah, I forget the name

  176. jjrh

    Cool, I'll have to take a closer look

  177. jjrh

    Wow okay I didn't realize res_xmpp could act as a component!